Eric Paris wrote: > For RHEL 5.2 I plan on adding a new field to a number of audit records. > The session id. Whenever the loginuid is set for a task a unique > session number will be assigned as well. The sessions number should > make it easier to coordinate future audit records (like syscalls and > avcs or whatever) to login records. Say root logs in twice at the same > time. It hard to determine which audit records belong to which root > login. > > An example can be seen below. Notice I added a ses= field right after > the auid= and uid= > > type=SYSCALL msg=audit(1197571662.907:27): arch=c000003e syscall=62 > success=yes exit=0 a0=1 a1=f a2=0 a3=0 items=0 ppid=2544 pid=2549 auid=0 > uid=0 gid=0 ses=2 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 > comm="bash" exe="/bin/bash" subj=root:system_r:unconfined_t:s0-s0:c0.c1023 > key=(null) > > type=LOGIN msg=audit(1197571780.103:31): login pid=2821 uid=0 old > auid=4294967295 new auid=0 old ses=4294967295 new ses=3 > > My real question is not whether this is a good idea but more how are the > certification tests going to react to having new information appear in > the records? I understand that sgrubb's audit log parsing library will > continue to happily work. I also think this placement is the best since > this information is used in aggregating logging information and > identifying messages having it near the beginning is appropriate. If > you disagree with the placement in general you are probably going to > have to repeat your disagreement on the audit list in a couple hours > when I push an actual patch upstream. > > But for RHEL5 I could maybe be convinced to put it at the end if it will > prove to be problematic. Since upstream and RHEL6 are going to have it > in the middle am I better off just putting it in the beginning/middle in > RHEL5 rather than the end?
I think our tests won't care about the placement as long as its not in the middle of a quoted string, which it isn't in this case. Thanks for asking. -- ljk > > -Eric > -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
