Hi Alex, Thanks for the excellent explanation. I've also checked how file system stores a symbolic link after reading your post. Now I know why symlink doesn't work as I thought ;-P
On Wed, Jan 1, 2014 at 2:29 AM, Alexander Viro <[email protected]> wrote: > On Tue, Dec 31, 2013 at 06:49:49PM +0800, Aaron Lewis wrote: >> Hi Alex, >> >> Sorry, I didn't make it clear. >> >> I need to protect all files under a directory, e.g /secure/ >> >> So if there's any newly created symlinks that points to files under >> that directory, e.g /secure/some_file, I will need to know. >> (/secure is not a symlink, but an existing directory) >> However "-a exit,always -F arch=b64 -S symlink -F success=1 -F >> dir=/secure" doesn't do the job. >> If I do "ln -s /secure/some_file /tmp/aa", no auditing log is generated > > ... because a symlink had been created in /tmp. > >> So I suspect auditing on symlink isn't for the source file/directory, >> but the target "string". > > The target string here is "/secure/some_file". > >> If I do "ln -s /bin/ls /secure/new_file", an auditing log is generated. > > ... since that creates a symlink in /secure, symlink's target being > "/bin/ls". > >> That's what I mean by "bug". > > Check which directory is modified by your commands. Really. ls -l /secure > will change after the second one, but will remain unchanged after the first > one. > > You can get notified when /secure is changed by symlink addition; you can > not get notifications whenever somewhere appears a symlink that would > resolve to something under /secure - see the posting upthread for the > reasons why that really can't be done. > > BTW, ln(1) manpage is atrocious. GNU variant suffers from the usual attitude > of GNU project towards manpages (they hate the need to be concise and > prefer info(1) to man(1)), but BSD variant isn't much better ;-/ > An honest variant would have to contain something like "ln(1) conflates > two unrelated functionalities - creating extra links to existing files > and creation of symlinks. The syntax is superficially similar in both > cases, but they would've been better off as separate commands." > > The thing is, original ln(1) syntax imitates that of cp(1) - ln from to > takes an existing file ("from") and makes "to" a new name for the same > file. Unlike cp(1), the file itself isn't copied - both directory > entries end up refering to the same object. Other forms also imitate cp(1) - > just as you can say cp <bunch of files> directory, you can say > ln <bunch of files> directory. > > ln -s is something entirely different. ln -s target name creates a new > symlink with "target" as contents. Target does *not* refer to a file; > it's just a string to be interpreted when pathname resolution steps into > name. > > That creates a nasty source of confusion - in the normal case (ln old new) > we are making the file "old" show up elsewhere ("new"), but in ln -s old new > we are making a symlink "new" that points to string "old". Note that > both cases invite the use of word 'target', but in completely different > meanings and applied to different ln(1) arguments ;-/ -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
