[PATCH] enable /proc/$$/loginuid

[Serge Hallyn]

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.

And by controlling when they access some auditable object, users might
be able to control the audited loginuid, rather than it being dictated
by the first uid logged in as, period.

Or am I misunderstanding the audit rules?  If it's the case that for any
user UID for whom we will want to audit any action, there will be an
AUDIT_UID rule at audit_filter_rules(), then I guess this patch is
unnecessary (except for the SELinux use).  It still means that any users
who log in before audit is enabled have no loginuid.  That may be fine
from a CAPP perspective.

-serge

On Tue, 2005-01-18 at 09:30 -0500, Stephen Smalley wrote:
> On Fri, 2005-01-14 at 19:58, Serge E. Hallyn wrote:
> > There is a bigger problem with the current loginuid assumptions.  The
> > loginuid is stored on the audit_context.  The audit_context is only
> > created when auditing has been enabled using auditctl, and an auditable
> > action has occurred.
> > 
> > Either we need to change the behavior to always create an audit_context
> > (with state=AUDIT_DISABLED) so long as AUDIT_SYSCALL is enabled, or we
> > need to move loginuid directly into the task_struct.
> 
> I'm not sure I follow.  First, the current code seems to always set up
> an audit context by default unless the task is explicitly marked
> non-auditable.  Second, even if an audit context does not exist, you can
> easily check for a null audit context and just return (uid_t)-1 in that
> case.  The loginuid serves no purpose for non-auditable tasks, and it
> seems wasteful to put it into the task struct.
> 
-- 
Serge Hallyn <serue at us.ibm.com>