No, I guess I've been misreading the code. Now the only remaining
reason for keeping that patch is to use loginuid when audit_enabled=0.
So I take the patch back :)
I will re-diff the netlink-loginuid patch without the loginuid-into-
taskstruct.patch and send it back out.
thanks,
-serge
On Tue, 2005-01-18 at 09:55 -0500, Stephen Smalley wrote:
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...
--
Serge Hallyn <serue(a)us.ibm.com>