Re: [RFC][PATCH 2/2] fanotify: support limited functionality for unprivileged users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux