Re: Recursive chown/chmod not showing enclosing directory

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! -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit