On Fri, 17 Jun 2005 11:44:38 EDT, Robert Love said: > I have been hesitant, though. I do not want feature creep to be a > deterrent to acceptance into the Linux kernel. I also think that there > could be arguments about security. Sending the event is one thing, > telling which pid (and thus what user, etc.) caused the event is > another. For example, we can make the argument that read rights on a > file are tantamount to the right to receive a read event. But can we > say that read rights are enough for a unprivileged user to know that > root at pid 820 is writing the file? I don't know. It's also racy as hell. By the time the inotify gets delivered to the userspace process, pid 820 may be long gone.....
Attachment:
pgpX4L2mT2Iue.pgp
Description: PGP signature
- Follow-Ups:
- Re: [patch] inotify, improved.
- From: Chris Friesen <[email protected]>
- Re: [patch] inotify, improved.
- From: Robert Love <[email protected]>
- Re: [patch] inotify, improved.
- References:
- [patch] inotify.
- From: Robert Love <[email protected]>
- Re: [patch] inotify.
- From: Zach Brown <[email protected]>
- Re: [patch] inotify.
- From: Robert Love <[email protected]>
- Re: [patch] inotify.
- From: Nick Piggin <[email protected]>
- Re: [patch] inotify.
- From: Robert Love <[email protected]>
- [patch] inotify, improved.
- From: Robert Love <[email protected]>
- Re: [patch] inotify, improved.
- From: Chris Friesen <[email protected]>
- Re: [patch] inotify, improved.
- From: Robert Love <[email protected]>
- [patch] inotify.
- Prev by Date: Re: [PATCH 1/1] SELinux: memory leak in selinux_sb_copy_data()
- Next by Date: Re: [PATCH 1/1] SELinux: memory leak in selinux_sb_copy_data()
- Previous by thread: Re: [patch] inotify, improved.
- Next by thread: Re: [patch] inotify, improved.
- Index(es):