On Fri, Jan 04, 2019 at 09:57:35AM -0500, Richard Guy Briggs wrote:

On 2019-01-03 18:50, Guenter Roeck wrote:

quoted

Hi Richard,

On Tue, Jul 31, 2018 at 04:07:36PM -0400, Richard Guy Briggs wrote:

quoted

The audit-related parameters in struct task_struct should ideally be
collected together and accessed through a standard audit API.

Collect the existing loginuid, sessionid and audit_context together in a
new struct audit_task_info called "audit" in struct task_struct.

Use kmem_cache to manage this pool of memory.
Un-inline audit_free() to be able to always recover that memory.

See: https://github.com/linux-audit/audit-kernel/issues/81

Signed-off-by: Richard Guy Briggs <redacted>

Overall I am not sure if keeping task_struct a bit smaller is worth
the added complexity, but I guess that is just me. 

The motivation was to consolidate all the audit bits into one pointer,
isolating them from the rest of the kernel, restricting access only to
helper functions to prevent abuse by other subsystems and trying to
reduce kABI issues in the future.  I agree it is a bit more complex.  It
was provoked by the need to add contid which seemed to make the most
sense as a peer to loginuid and sessionid, and adding it to task_struct
would have made it a bit too generic and available.

This is addressed at some length by Paul Moore here in v2:
	https://lkml.org/lkml/2018/4/18/759

That makes sense. Thanks a lot for the clarification.

Guenter