Messages in this thread | | | Date | Fri, 26 Mar 2004 11:12:01 +0100 | From | Rüdiger Klaehn <> | Subject | Re: [RFC,PATCH] dnotify: enhance or replace? |
| |
viro@parcelfarce.linux.theplanet.co.uk wrote:
[snip]
> "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 racy;
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 no problem.
> 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. > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |