linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Timothy R. Chavez" <tinytim@us.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-audit@redhat.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	David Woodhouse <dwmw2@infradead.org>,
	Mounir Bsaibes <mbsaibes@us.ibm.com>,
	Steve Grubb <sgrubb@redhat.com>, Serge Hallyn <serue@us.ibm.com>,
	Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	Klaus Weidner <klaus@atsec.com>, Chris Wright <chrisw@osdl.org>,
	Stephen Smalley <sds@tycho.nsa.gov>, Robert Love <rml@novell.com>,
	Christoph Hellwig <hch@infradead.org>,
	Daniel H Jones <danjones@us.ibm.com>,
	Amy Griffis <amy.griffis@hp.com>,
	Maneesh Soni <maneesh@in.ibm.com>
Subject: Re: [PATCH] audit: file system auditing based on location and name
Date: Wed, 6 Jul 2005 16:50:08 -0700	[thread overview]
Message-ID: <20050706235008.GA9985@kroah.com> (raw)
In-Reply-To: <200507061523.11468.tinytim@us.ibm.com>

On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> This is similar to Inotify in that the audit subsystem watches for file
> system activity and collects information about inodes its interested 
> in, but this is where the similarities stop.  Despite the fact that the
> Inotify requirements only dictate a subset of the activity the audit
> subsystem is interested in, there is a more fundamental divergence 
> between the two projects.  Like audit, Inotify takes paths and resolves 
> them to a single inode.  But, unlike audit, Inotify does not find the path 
> itself interesting.

Huh?  inotify users find that path interesting, as they use it to act
apon.

> Much like the (device,inode)-based system call filters 
> currently available in the audit subsystem, Inotify targets only individual 
> inodes.  Thus, if the underlying inode associated with the file /etc/shadow 
> was changed, and /etc/shadow was being "watched", we'd lose auditability 
> on /etc/shadow across transactions.

That's why you watch /etc/ instead, which catches that rename.  That
being said, why would not inotify also want this functionality if you
think it is important?

> More so, Inotify cannot watch inodes that do not yet exist (because
> the file does not yet exist).  To do this, the audit subsystem must
> hook deeper than Inotify (in fs/dcache.c) to adapt with the file
> system as it changes.  Where it makes sense, the small set of
> notification hooks in the VFS that Inotify and audit could share
> should be consolidated.

As inotify works off of open file descriptors, yes, this is true.  But,
again, if you think this is really important, then why not just work
with inotify to provide that kind of support to it?

I suggest you work together with the inotify developers to hash out your
differences, as it sounds like you are duplicating a lot of the same
functionality.

Also, inotify handles the namespace issues of processes by working off
of a file descriptor.  How do you handle this?

Do you have any documetation or example userspace code that shows how to
use this auditfs interface you have created?

thanks,

greg k-h

  reply	other threads:[~2005-07-06 23:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-06 16:54 [PATCH] audit: file system auditing based on location and name Timothy R. Chavez
2005-07-06 17:17 ` Greg KH
2005-07-06 20:23 ` Timothy R. Chavez
2005-07-06 23:50   ` Greg KH [this message]
2005-07-07  1:33     ` Steve Grubb
2005-07-07 18:15       ` Greg KH
2005-07-07 18:49         ` Steve Grubb
2005-07-07 19:04           ` Greg KH
2005-07-07 19:48             ` Steve Grubb
2005-07-07 21:31               ` Arjan van de Ven
2005-07-07 22:08                 ` Timothy R. Chavez
2005-07-07 22:51                   ` serue
2005-07-08  5:33                     ` Arjan van de Ven
2005-07-08  5:48                       ` James Morris
2005-07-08 17:48               ` Greg KH
2005-07-07 16:26     ` Timothy R. Chavez
2005-07-07 18:10       ` Greg KH
2005-07-07 18:16         ` David Woodhouse
2005-07-07 18:18           ` Greg KH
2005-07-07 19:49         ` Timothy R. Chavez
2005-07-08 17:46           ` Greg KH
2005-07-08 19:48             ` Timothy R. Chavez
2005-07-10 18:59               ` Greg KH
     [not found]                 ` <OF993CB74B.E135A576-ON8725703B.00568CD6-0525703B.005814C3@us.ibm.com>
2005-07-11 17:13                   ` Greg KH
2005-07-09  1:10   ` Chris Wright
2005-07-09  2:10     ` Timothy R. Chavez
2005-07-07  6:40 ` Arjan van de Ven
2005-07-07  6:50   ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050706235008.GA9985@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@osdl.org \
    --cc=amy.griffis@hp.com \
    --cc=chrisw@osdl.org \
    --cc=danjones@us.ibm.com \
    --cc=dwmw2@infradead.org \
    --cc=hch@infradead.org \
    --cc=klaus@atsec.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    --cc=mbsaibes@us.ibm.com \
    --cc=rml@novell.com \
    --cc=sds@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --cc=sgrubb@redhat.com \
    --cc=tinytim@us.ibm.com \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).