On Mon, May 19, 2025 at 12:03 PM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Sat, Apr 19, 2025 at 12:06:57PM +0200, Amir Goldstein wrote: > > An unprivileged user is allowed to create an fanotify group and add > > inode marks, but not filesystem, mntns and mount marks. > > > > Add limited support for setting up filesystem, mntns and mount marks by > > an unprivileged user under the following conditions: > > > > 1. User has CAP_SYS_ADMIN in the user ns where the group was created > > 2.a. User has CAP_SYS_ADMIN in the user ns where the filesystem was > > mounted (implies FS_USERNS_MOUNT) > > OR (in case setting up a mntns or mount mark) > > 2.b. User has CAP_SYS_ADMIN in the user ns associated with the mntns > > So the crux of the problem is that we need to be sure that for all > options we need to be sure that the scope of the permission guarantees > necessary privileges over all the associated objects are held. > > CAP_SYS_ADMIN in the owning user namespace of the filesystem (1.) seems > trivially ok because it means that the caller has privileges to mount > that filesystem. > > If the caller is just privileged over the owning user namespace of the > mount namespace (2.b) then they are able to listen for mount > notifications starting with v6.15. Note how that the permissions are > specifically scoped to mount objects in that api. > > But what you're trying to do here is not scoped to mounts. You're using > that permission check to delegate privileges over non-mount objects such > as directories accessible from that mount as well. > > IOW, if I set up a mount mark on a mount based on the fact that I have > privileges over that mount's owning users namespace then it reads to me > that if I have: > > mount --bind-into-unprvileged-container /etc /my/container/rootfs/etc > > such that the new bind-mount for /etc that gets plugging into the > container is owned by the unprivileged containers's mount namespace then > the container can see write/open/read events on /etc/passwd and > /etc/shadow? But that bind-mount exposes the host's /etc/shadow and > /etc/passwd. That seems like a no go to me. > You are absolutely right. This is why I change the mount mark to require same privileges as filesystem mark in v3: https://lore.kernel.org/linux-fsdevel/20250516192803.838659-1-amir73il@xxxxxxxxx/ Sorry that I have not clarified this in this thread. Thanks, Amir.
