Re: [PATCH] loginuid change logging details

[Steve Grubb <sgrubb@redhat.com>]

On Friday, January 17, 2014 06:34:56 PM Richard Guy Briggs wrote:
> I missed posting this before the holidays.  I discovered this while adding
> other information to other message types.
> 
> It seemed to me that loginuid changes were significantly missing context
> references.  This patch adds that.  Is this sufficient, or is there more
> information missing too?  If this is sufficient, stop reading this cover
> letter and review the patch.  If it is not sufficient, keep reading
> below...
> 
> The question has been raised that perhaps we should be switching this to use
> audit_log_task_info() istead which adds a whole lot more information about
> this task.
> 
> In the existing message
> 	pid
> 	uid
> are already given, before
> 	old-auid
> 	new-auid
> 	old-ses
> 	new-ses

I'd rather have old-auid/ses and auid/ses so that I don't have to expand 
everything to start looking for 'new-' variants. think of all the values as 
current as of when the syscall completes successfully and the proposed values 
if denied.

-Steve


> The function audit_log_task_info() gives:
> 	ppid
> 	pid
> 	auid
> 	uid
> 	gid
> 	euid
> 	suid
> 	fsuid
> 	egid
> 	sgid
> 	fsgid
> 	tty
> 	ses
>         comm
> 	exe
> 	res
> .
> 
> So,
> 	pid
> 	uid
> are in the right order, along with
> 	new-auid (auid)
> 	new-ses (ses)
> but if we give the
> 	old-auid
> 	old-ses
> values first, then call audit_log_task_info(), the old values will preceed
> 	pid
> 	uid
> .
> 
> Is this re-ordering acceptable to gain more information and reduce code
> duplicity?
> 
> 
> Richard Guy Briggs (1):
>   audit: log task context when setting loginuid
> 
>  kernel/auditsc.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)