Re: [PATCH] enable /proc/$$/loginuid
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(a)us.ibm.com>