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

Re: [RFC][PATCH] (#2) Prelim in-kernel file system auditing support



On Thu, 27 Jan 2005 00:57:03 -0500, Valdis Kletnieks vt edu
<Valdis Kletnieks vt edu> wrote:
> On Wed, 26 Jan 2005 23:42:10 CST, "Timothy R. Chavez" said:
> 
> > Unless, I was doing something wrong.  When I tested a watch point on
> > both "/etc" and "passwd".  When I issued a "cat /etc/passwd" only a
> > record for "passwd" was generated.  Then, when I did a "cat /etc", I
> > received a record for "etc" -- I was only recording open() syscalls,
> > however.
> 
> Ah.. Yes.. it won't call open() on /etc on the way to /etc/passwd.
> There's OTHER places that you get hooks in that case.
> 
> Look around in fs/namei.c - link_path_walk ends up calling permission()
> on each component of the path in turn - and permission() ends up doing all
> the grunt work (file modes, ACLs, LSM, etc...)
> 
So then, in theory, when I do a "cat /etc/passwd" and both "etc/" and
"passwd" are being watched and the open syscall() will generate an
audit record, I should see a record for both file system objects in
the audit log.  For the open syscall(), there should be a message for
"etc" and "passwd", right?  Because if I hit the permission() for
"etc" and "passwd" I should be adding both "etc" and "passwd" to the
audit context for the open() because they are both being watched.  I
was only getting a record for "passwd"

This will be the first thing I look at tommorow morning at work.
> 
> 


-- 
- Timothy R. Chavez


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