From Fedora Project Wiki
(Created page with 'Things that need to be fixed: * support non-root users') |
No edit summary |
||
(9 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
Things that need to be fixed: | Things that need to be fixed: | ||
* | * Ignore masks, so that events on files can be ignored until the files are modified. | ||
* Support for access decisions (by privileged processes). | |||
* Per mount point notification (general subtree notification seems too hard). | |||
** Clarify how mount point marks should propagate to new mounts from parent mounts, when creating a new bind mount, and to existing bind mounts. | |||
* Include uid, not just pid. | |||
Probably for the next round: | |||
* Add a flag to turn off event merging (or make merging less aggressive) so that events will happen "in order"? | |||
* Support non-root processes (will require permission checks). | |||
** Reliable vs. non-reliable delivery: cannot allow non-privileged processes to have arbitrarily long event queues. | |||
* Support directory events by passing an fd to the directory. | |||
* Think about mark propagation across directories. | |||
* Allow users to get a watch descriptor (as with inotify) instead of a file descriptor if desired. (Controversial.) | |||
* inotify or denotify don't generate events for deleted inodes. Deleted inodes may still be accessed via open file descriptors though, so it may make sense to continue generating fanotify events. |
Latest revision as of 17:34, 26 October 2009
Things that need to be fixed:
- Ignore masks, so that events on files can be ignored until the files are modified.
- Support for access decisions (by privileged processes).
- Per mount point notification (general subtree notification seems too hard).
- Clarify how mount point marks should propagate to new mounts from parent mounts, when creating a new bind mount, and to existing bind mounts.
- Include uid, not just pid.
Probably for the next round:
- Add a flag to turn off event merging (or make merging less aggressive) so that events will happen "in order"?
- Support non-root processes (will require permission checks).
- Reliable vs. non-reliable delivery: cannot allow non-privileged processes to have arbitrarily long event queues.
- Support directory events by passing an fd to the directory.
- Think about mark propagation across directories.
- Allow users to get a watch descriptor (as with inotify) instead of a file descriptor if desired. (Controversial.)
- inotify or denotify don't generate events for deleted inodes. Deleted inodes may still be accessed via open file descriptors though, so it may make sense to continue generating fanotify events.