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(-)