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(a)neovalent.com