Re: [RFC,PATCH] dnotify: enhance or replace?

[viro@parcelfarce.linux.theplanet.co.uk]

On Wed, Mar 24, 2004 at 02:53:52PM -0500, John McCutchan wrote:
> - When user passes fd to kernel to watch, the kernel takes over this
>   fd, making it invalid in user space ( I know this is a terrible hack)
>   then when a volume is unmounted, the kernel can walk the list of 
>   open fd's using for notifacation and close them, before attempting to
>   unmount.

And if umount fails?  BTW, _which_ umount?  The sucker can be present
in more than one place in more than one namespace.
 
> - The user passes a path to the kernel, the kernel does some work so
>   that it can track anything to do with that path, and again when
>   an unmount is called the kernel cleans up anything used for
>   notification. 

Ditto.

> Both of these ideas are similar, does anyone have a better idea?

"Doctor, It Hurts When I Do It"

Seriously, dnotify sucks in a lot of ways, starting with the basic
premise - that userland can do notification-based maintainig of directory
tree image.  It's racy by definition, so any attempts to use it for
"security improvements" are scam.  Which leaves us with file manglers
and their ilk.

Note that any attempts to trace "aliases" in userland are hopelessly racy;
that mounting/unmounting doesn't even show on the radar; that different
users can see different parts of tree or, while we are at it, completely
different trees; that this crap is a DDoS on a server that exports any
sort of network filesystem to many clients - *especially* if you want
notifications on the entire tree.

IOW, idea is fundamentally flawed and IMO the real fix is to try and figure
out a decent UI that would provide what file managers are really used for.