[RFC][PATCH 3/3] CAPP-compliant file system auditing

[Timothy R. Chavez]

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