--- Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
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.
Is it impossible for a task to change from
non-auditable to auditable without setting
the loginuid?
Is it possible for an auditable task to
perform an auditable action on the behalf
of a non-auditable task? An example here
might be a non-auditable GUI making a
request of the X11 server, or a non-auditable
cluster management daemon using a remote
service via xinetd. In either case the
auditable task needs the loginuid of the
non-auditable task in order to ensure that
auditing is done properly.
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.
I'm sure an evaluation team would get a kick
out of finding that in the audit system
description.
The loginuid serves no purpose for
non-auditable tasks, and it
seems wasteful to put it into the task struct.
While the loginuid may not be directly useful
to a task that never generates audit records
it may be useful for other tasks that are doing
work on that task's behalf.
The audituid of xinetd is rarely interesting.
The audituid of a task that makes a request of
xinetd is usually interesting.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo