Recursive chown/chmod not showing enclosing directory

[Mark Moseley]

Hi. Didn't realize this was a closed list till I started wondering why
the automated invite hadn't shown up :)

Just a quick question: I'm working on parsing audit logs and I noticed
one oddity. If a chown or chmod is done recursively on a directory
(and I imagine there are other examples than chown/chmod) done from
somewhere outside the affected directory, in the audit log entries for
the *files* within those directories, there's no way to track back
what directory the files live in.

Example:

>From /tmp, doing a "chown -R 0 /home/moseley/tmp/tmp/", where the
contents of /home/moseley/tmp/tmp/ are two files, 'a' and 'b' (I've
added spacing to make it more readable):

type=SYSCALL msg=audit(1349375745.138:4143): arch=c000003e syscall=260
success=yes exit=0 a0=4 a1=77a988 a2=0 a3=ffffffff items=1 ppid=5775
pid=19589 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts13 ses=3387 comm="chown" exe="/bin/chown" key=(null)
type=CWD msg=audit(1349375745.138:4143):  cwd="/tmp"
type=PATH msg=audit(1349375745.138:4143): item=0 name="b"
inode=2367514 dev=08:02 mode=0100664 ouid=1000 ogid=1000 rdev=00:00
---
type=SYSCALL msg=audit(1349375745.138:4144): arch=c000003e syscall=260
success=yes exit=0 a0=4 a1=782b08 a2=0 a3=ffffffff items=1 ppid=5775
pid=19589 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts13 ses=3387 comm="chown" exe="/bin/chown" key=(null)
type=CWD msg=audit(1349375745.138:4144):  cwd="/tmp"
type=PATH msg=audit(1349375745.138:4144): item=0 name="a"
inode=2367514 dev=08:02 mode=0100664 ouid=0 ogid=1000 rdev=00:00
---
type=SYSCALL msg=audit(1349375745.138:4145): arch=c000003e syscall=260
success=yes exit=0 a0=ffffffffffffff9c a1=779520 a2=0 a3=ffffffff
items=1 ppid=5775 pid=19589 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts13 ses=3387 comm="chown" exe="/bin/chown"
key=(null)
type=CWD msg=audit(1349375745.138:4145):  cwd="/tmp"
type=PATH msg=audit(1349375745.138:4145): item=0
name="/home/moseley/tmp/tmp/" inode=2367031 dev=08:02 mode=040775
ouid=1000 ogid=1000 rdev=00:00


In the first two entries, there's no indication that 'a' or 'b' live
in /home/moseley/tmp/tmp/.

In the case of a non-relative chown/chmod (e.g. chown'ing
/home/moseley/tmp/tmp/a), the 'item=0' line has the full pathname to
/home/moseley/tmp/tmp/a in its entry.

My question is, is there anything in these entries that I might be
missing that ties the first two back to the 3rd? I'm building a
tracking system for 'changed/written' files, so I change all 'item'
pathnames into absolute pathnames, but in this case, I'm at a loss as
to how to (programmatically) tie them together, beyond "pid". Or
better yet, is there some flag in the first two entries that I might
be missing that shows that they're 'children' of the third entry.

I'm not crazy about the idea of building some of state into my parsing
(i.e. I see a relative chown/chmod 'item' entry, so stash these and
keep watching for chown/chmod's with the same PID) but if that's my
only option, then that's my only option. But I figured I'd ask to see
if there was something far more clever than I'm missing (possibly in
plain sight).

Thanks!