On Tue, 2005-01-18 at 09:50, Stephen Smalley wrote:
We'd like to have it available for programs like newrole, but
that is
run from a user session and should thus already be auditable. Given
that an audit context is always set up unless the task is explicitly
marked non-auditable, and the only task likely to be marked
non-auditable is the audit daemon itself, I'm not sure why it matters.
Notice that at the point where an audit context is created for the task,
we don't have any criteria for determining whether the task should be
audited other than the pid and its parent task information. That is why
an audit context is almost always created, even if it isn't used in the
end.
BTW, I'm not fundamentally opposed to adding the loginuid to the task
struct, but I would tend to expect more resistance upstream to adding it
unless it can truly be justified. And I'm not sure that it is
justified...
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency