On Tue, Feb 16, 2021 at 7:01 PM Jan Kara [off-list ref] wrote:

On Sun 24-01-21 20:42:04, Amir Goldstein wrote:

quoted

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@gmail.com>

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.