audit_context and loginuid on older kernels

["Andy Fanton" <andy@neovalent.com>]

Hey Everyone -

I'm hoping someone on this list can help me understand some things about the loginuid that is supposedly stored in the audit_context
struct that is pointed to by the task_struct.

I'm working on a LKM that is part of a security/forensics product.  I have a LKM that simply wants to know the original logged-in
uid in a given context when that user has SU-ed to root and an process he launched makes a syscall I care about.

My driver attempts to obtain this by calling audit_get_loginuid() which returns the loginuid member of the audit_context structure
on kernels older than 2.6.24.  For newer kernels this function is implemented as a macro that returns the loginuid member of
task_struct (the place this value was moved to when removed from the audit_context struct.

On some systems this works fine (RHEL 5.x for instance with 2.6.18-x kernels).  On all of the post 2.6.24 kernels it seems to work
fine as well (of the machines I've tested anyway).
However, for some systems I am testing on (SuSE 10.2 with 2.6.16.60 kernels) audit_get_loginuid() seems to always return -1.

In one case with a 2.6.16.60 32 bit kernel the audit_context value in the task_struct (I'm using 'current' in the context of a
syscall) is a sane value, but when I call audit_get_loginuid() it returns -1.

Another case (same 2.6.16.60 kernel but 64-bit) the audit_context value in the task_struct is NULL.

Is there a trick I couldn't find in the kernel sources or docs for configuring a system (or the audit subsystem) to actually fill in
the loginuid values with the real loginuid?  I can't recompile the kernel because this product has to work with shipping commercial
distributions.

Or, is there some other (better) way I could figure out what the original logged-in uid is for a given context (again, I'm in the
context of a syscall within my LKM)?

Any help in figuring this out is greatly appreciated.  Thank you in advance!

Andy Fanton
andy@neovalent.com