[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: audit 0.6 release

--- David Woodhouse <dwmw2 infradead org> wrote:

> On Fri, 2005-01-07 at 11:20 +1100, Leigh Purdie
> wrote:
> > 
> > Tom can correct me here, but I suspect that
> ideally:
> > * symlinks and links should be resolved. (even if
> the file linked to
> > no longer actually exists - the final path name
> should still be
> > reported/filtered on).

There will be times when one will wish to filter
on any of
   - The pathname requested
   - The pathname resolved
   - One of the other names of the object

> > Ideally, access to an
> symlink will actually
> > generate TWO events - one for the symlink (open -
> read), one for the
> > final file (open - as per user requirement).

Erg. That logic implies that you'd want a record
for each directory the lookup passes through.
Don't think that that has never been seriously
considered, BTW.
> That's a meaningful statement for symlinks but not
> for hard links. With
> hard links there is no one 'final path name';
> they're all just different
> names for the same inode. If I hard-link /etc/passwd
> to /tmp/fish then
> both of those are _real_ names for it.

That is correct. In this case what you want to
do is
    - Get the pathname of the object you want
      to filter on (/etc/passwd)
    - Fetch the dev/inode information
    - For each record that comes out look
      for either the name you requested or
      the dev/inode pair.
    - When you see the pathname unlinked you
      might forget the dev/inode, but since
      when it was /etc/passwd you cared about
      it who's to say you don't now, just
      because it has a different name?
    - When /etc/passwd is renamed to /etc/opasswd
      do you want to stop watching it?
      This could go either way.
    - When you see the pathname created you
      refetch the dev/inode

> It would be almost impossible to implement a system
> which is asked to
> log 'all access to /etc/*' and includes in that the
> access to /tmp/fish.

Costly, yes.

Casey Schaufler
casey schaufler-ca com

Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]