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(-) -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
