On Tue, Feb 16, 2021 at 7:01 PM Jan Kara <jack@xxxxxxx> wrote: > > On Sun 24-01-21 20:42:04, Amir Goldstein wrote: > > Add limited support for unprivileged fanotify event listener. > > An unprivileged event listener does not get an open file descriptor in > > the event nor the process pid of another process. An unprivileged event > > listener cannot request permission events, cannot set mount/filesystem > > marks and cannot request unlimited queue/marks. > > > > This enables the limited functionality similar to inotify when watching a > > set of files and directories for OPEN/ACCESS/MODIFY/CLOSE events, without > > requiring SYS_CAP_ADMIN privileges. > > > > The FAN_REPORT_DFID_NAME init flag, provide a method for an unprivileged > > event listener watching a set of directories (with FAN_EVENT_ON_CHILD) > > to monitor all changes inside those directories. > > > > This typically requires that the listener keeps a map of watched directory > > fid to dirfd (O_PATH), where fid is obtained with name_to_handle_at() > > before starting to watch for changes. > > > > When getting an event, the reported fid of the parent should be resolved > > to dirfd and fstatsat(2) with dirfd and name should be used to query the > > state of the filesystem entry. > > > > Note that even though events do not report the event creator pid, > > fanotify does not merge similar events on the same object that were > > generated by different processes. This is aligned with exiting behavior > > when generating processes are outside of the listener pidns (which > > results in reporting 0 pid to listener). > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > The patch looks mostly good to me. Just two questions: > > a) Remind me please, why did we decide pid isn't safe to report to > unpriviledged listeners? Just because the information that process X modified file Y is not an information that user can generally obtain without extra capabilities(?) I can add a flag FAN_REPORT_OWN_PID to make that behavior explicit and then we can relax reporting pids later. > > b) Why did we decide returning open file descriptors isn't safe for > unpriviledged listeners? Is it about FMODE_NONOTIFY? > Don't remember something in particular. I feels risky. > I'm not opposed to either but I'm wondering. Also with b) old style > fanotify events are not very useful so maybe we could just disallow all > notification groups without FID/DFID reporting? In the future if we ever > decide returning open fds is safe or how to do it, we can enable that group > type for unpriviledged users. However just starting to return open fds > later won't fly because listener has to close these fds when receiving > events. > I like this option better. Thanks, Amir.
