[PATCH] enable /proc/$$/loginuid

[Serge Hallyn]

That had been my original understanding, but I got some very odd results
over the weekend which led me to reread (and misread) the code.  Namely,
I missed the exit default in audit_filter_task() being
AUDIT_BUILD_CONTEXT.

thanks,
-serge

On Tue, 2005-01-18 at 10:10 -0500, Stephen Smalley wrote:
> On Tue, 2005-01-18 at 11:15, Serge Hallyn wrote:
> > I'm assuming the loginuid needs to be set at the first login, and be
> > immutable.  Let's say we have an audit rule for some inode ino.  A task
> > accessing that inode won't have an audit_context until it touches that
> > inode.  So there's no loginuid to associate with that action at that
> > time.
> 
> I don't believe that this is how the current audit code works.  An audit
> context is initially set up for a task upon fork/clone via
> copy_process-> audit_alloc.  audit_alloc calls audit_filter_task to see
> if the task has auditing completely disabled (which must be explicit;
> the default is to build a context in the absence of any filters to
> disable).  Unless auditing is completely disabled for the task,
> audit_alloc creates an audit context for the task, preserves the
> loginuid from the parent (with my fix), and sets the syscall auditing
> flag.  Subsequently, audit-related information (e.g. paths, inodes,
> devices) is captured during syscalls made by the task, and at syscall
> exit, audit_syscall_exit calls audit_get_context, which now checks
> filters to see if it should mark the context as auditable (and any
> earlier calls to audit_log during the syscall e.g. by SELinux will have
> already marked it auditable).  If auditable, audit_syscall_exit will
> then call audit_log_exit to perform the actual logging.
> 
> It has to work in this way for the reason you describe - we don't know
> whether the task will trigger any auditable events a priori, so we must
> set up an audit context and start capturing information unless the task
> is explicitly marked as not requiring any auditing at all.
> 
-- 
Serge Hallyn <serue at us.ibm.com>