Thread (33 messages) flat view 33 messages, 3 authors, 2021-03-28

Re: [PATCH v2 0/2] unprivileged fanotify listener

From: Amir Goldstein <amir73il@gmail.com>
Date: 2021-03-17 11:02:43
Also in: linux-fsdevel

On Tue, Mar 16, 2021 at 5:55 PM Jan Kara [off-list ref] wrote:
On Thu 04-03-21 13:29:19, Amir Goldstein wrote:
quoted
Jan,

These patches try to implement a minimal set and least controversial
functionality that we can allow for unprivileged users as a starting
point.

The patches were tested on top of v5.12-rc1 and the fanotify_merge
patches using the unprivileged listener LTP tests written by Matthew
and another LTP tests I wrote to test the sysfs tunable limits [1].
Thanks. I've added both patches to my tree.
Great!
I'll go post the LTP tests and work on the man page updates.

BTW, I noticed that you pushed the aggregating for_next branch,
but not the fsnotify topic branch.

Is this intentional?

I am asking because I am usually basing my development branches
off of your fsnotify branch, but I can base them on the unpushed branch.

Heads up. I am playing with extra privileges we may be able to
allow an ns_capable user.
For example, watching a FS_USERNS_MOUNT filesystem that the user
itself has mounted inside userns.

Another feature I am investigating is how to utilize the new idmapped
mounts to get a subtree watch functionality. This requires attaching a
userns to the group on fanotify_init().

<hand waving>
If the group's userns are the same or below the idmapped mount userns,
then all the objects accessed via that idmapped mount are accessible
to the group's userns admin. We can use that fact to filter events very
early based on their mnt_userns and the group's userns, which should be
cheaper than any subtree permission checks.
<\hand waving>

Thanks,
Amir.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help