Re: [RFC,PATCH] dnotify: enhance or replace?
From: Rüdiger Klaehn
Date: Fri Mar 26 2004 - 05:11:51 EST
> "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.
I thought about this some more. If you watch for e.g. all writes on the
root of a file system you get a complete, correctly ordered log of all
file writes on that filesystem. So you can find out wether a certain
file has been changed or not. That could be relevant security information.
You would get changes to the file pointed to by the path /etc/shadow,
even if the file has been changed by a hard link from /tmp/bla.
I am assuming here that there is a way like inode numbers to uniquely
identify and persistently identify a file. If something like this does
not exist, you are out of luck.
> Note that any attempts to trace "aliases" in userland are hopelessly
You don't trace aliases in userland. All the relevant information is
logged in kernel space. The only thing you do in userspace is to convert
this information into a user readable form. You can take as long as you
want for that.
Btw: why did you put aliases in quotes? Is aliases not the correct term
when refering to multiple paths pointing to the same file?
> that mounting/unmounting doesn't even show on the radar;
There is an event for mounting and unmounting.
> hat different users can see different parts of tree or, while we are
> at it, completely different trees;
That is why the paths returned by the mechanism are relative to the
directory from which you watch.
> 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.
If you have 100 clients, and each client wants its own notification for
/home, you would indeed have a problem. But if a single process like fam
watches for changes in /home on behalf of all 100 clients, it would be
> IOW, idea is fundamentally flawed and IMO the real fix is to try and
> out a decent UI that would provide what file managers are really used
File managers are just one application of an enhanced file change
notification mechanism. There are many much more interesting
applications. For file managers the current dnotify mechanism is OK.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/