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.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency