Re: [RFC][PATCH 3/3] CAPP-compliant file system auditing
On Thursday 31 March 2005 03:02 pm, Stephen Smalley wrote:
I'm not sure why yet, but I end up with three different inode
numbers
involved in the resulting audit messages, two different ones for the two
auxitem records on the shadow watch (which both have name "shadow"), and
a third inode number listed for both /etc/nshadow and /etc/shadow on the
regular item list collected during pathname resolution. For the watch-
generated ones, I expected the same inode number (since it is a rename
and involves no change); for the regular items, I expected
the /etc/nshadow inode number to correspond with that same inode number
(since it is the file that is renamed to /etc/shadow), with
the /etc/shadow inode number being the original inode number of the old
file. Seems to bear investigation...
Its clearer when you audit /etc/nshadow too:
audit(1112312855.601:11168432): syscall=38 exit=0
audit(1112312855.601:11168432): auxitem=1 name="shadow" filterkey=SHADOW
perm=2 perm_mask=2 inode=131125
audit(1112312855.601:11168432): auxitem=1 name="shadow" filterkey=SHADOW
perm=2 perm_mask=2 inode=130359
audit(1112312855.601:11168432): auxitem=1 name="nshadow" filterkey=NSHADOW
perm=2 perm_mask=2 inode=131125
audit(1112312855.601:11168432): item=0 name="/etc/nshadow" inode=130305
audit(1112312855.601:11168432): item=1 name="/etc/shadow" inode=130305
Order is tricky, the last aux record is the first thing that happened. We
move from /etc/nshadow (first may_delete() in vfs_rename()) to /etc/shadow
(second may_delete() in vfs_rename()), which overwrites it with /etc/shadow
(vfs_rename_other())
Also the inode reported in the item records is actually the parent
directory :)
ls -di /etc/
130305 /etc/
--
-tim