Steve Grubb wrote:
This should be a separate thread since the topic is different.
On Wednesday 15 February 2006 11:14, Linda Knippers wrote:
>Amy submitted a patch a while back to eliminate the "name=" field
>to avoid "name=(null)" from the audit records if there was no name
>but I don't think the patch went anywhere.
Right. I want all audit fields to have name=value. If we have %s in the
message and pass NULL to it, snprintf is already going to put "(null)" so
what's wrong with just using this precedent?
The problem is that "(null)" is a valid file name.
[ljk@cert-e2 ~]$ touch "(null)"
[ljk@cert-e2 ~]$ ls -l "(null)"
-rw-rw-r-- 1 ljk ljk 0 Feb 17 11:14 (null)
When I look at audit records generated by those commands I see records
like this:
type=SYSCALL msg=audit(1140192875.311:3789): arch=c000003e syscall=132
success=yes exit=0 a0=7fbffffc51 a1=0 a2=1b6 a3=0 items=1 pid=2116
auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501
fsgid=501 comm="touch" exe="/bin/touch"
type=CWD msg=audit(1140192875.311:3789): cwd="/home/ljk"
type=PATH msg=audit(1140192875.311:3789): name="(null)" flags=1
inode=6537222 dev=fd:01 mode=0100664 ouid=501 ogid=501 rdev=00:00
How can I tell from the audit records that the file name was "(null)"
vs. having "(null)" manufactured by the audit system?
-- ljk
>It looks like there's a new case (for tty) where "(none)" is used.
Yes for the same reason.
>It would be nice to avoid having this in the audit records, especially
>in this case where the value might never be set on a particular system.
It creates parsing problems without a value. If I saw "tty=" and that's
all,
I'd think the audit system malfunctioned and file a bugzilla. I don't want
that.
-Steve