lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 15 Dec 2009 16:42:20 +0530
From:	Niraj kumar <niraj17@...il.com>
To:	Andreas Gruenbacher <agruen@...e.de>,
	Eric Paris <eparis@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	viro@...iv.linux.org.uk
Subject: Re: [PATCH 1/5] fsnotify/vfsmount: add fsnotify fields to struct 
	vfsmount

On Thu, Dec 10, 2009 at 10:01 PM, Andreas Gruenbacher <agruen@...e.de> wrote:
> On Friday 04 December 2009 16:39:25 Christoph Hellwig wrote:
>> What's the rationale for adding them?
>
> The idea is to provide a mechanism to watch for "all events", but in a
> namespace aware way: for that, a process registers interest in all mount
> points it can reach.  With the previous hack, a global "I want it all" flag,
> per-namespace listeners were not possible.
>
> Root can use bind mounts onto themselves (e.g., mount --bind /foo/bar
> /foo/bar) to watch arbitrary directories with the per-mount-point mechanism.
> Mount as user will open up additional use cases.
>
> It would be nice to be able to register interest in all events below a
> directory which is not a mount point, too.  The problem with that is that the
> number of cached inodes below a given directory could be huge -- and we would
> have to visit them all atomically in order to "mark" them, which is not
> feasible.  The per-mount-point mechanism will eventually give us *almost* the
> same, and so I believe it's good enough.
>

As another dimension of the same problem, it would be nice to
register interest in events generated by only a particular set of processes.
As a special case of this, can I register only for events generated
by myself and all my child processes. Is it already covered in some way?

There are situations where this could be very useful. One such case could be
somebody wanting to audit any random application. Collecting data for the whole
system and then filtering might be possible, but maynot be very efficient.
It might be good to add this while we are at it.

Let me know if I am missing something.

-Niraj
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ