From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
Matthew Bobrowski <mbobrowski@mbobrowski.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Christian Brauner <christian.brauner@ubuntu.com>
Subject: Re: [PATCH v2 0/2] unprivileged fanotify listener
Date: Wed, 17 Mar 2021 12:42:07 +0100 [thread overview]
Message-ID: <20210317114207.GB2541@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxgCv42_xkKpRH-ApMOeFCWfQGGc11CKxUkHJq-Xf=HnYg@mail.gmail.com>
On Wed 17-03-21 13:01:35, Amir Goldstein wrote:
> On Tue, Mar 16, 2021 at 5:55 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Thu 04-03-21 13:29:19, Amir Goldstein wrote:
> > > 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?
Not really, pushed now. Thanks for reminder.
> 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>
Yeah, I agree this should work. Just it seems to me the userbase for this
functionality will be (at least currently) rather limited. While full
subtree watches would be IMO interesting to much more users.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-03-17 11:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 11:29 [PATCH v2 0/2] unprivileged fanotify listener Amir Goldstein
2021-03-04 11:29 ` [PATCH v2 1/2] fanotify: configurable limits via sysfs Amir Goldstein
2021-03-04 11:29 ` [PATCH v2 2/2] fanotify: support limited functionality for unprivileged users Amir Goldstein
2021-03-16 15:55 ` [PATCH v2 0/2] unprivileged fanotify listener Jan Kara
2021-03-17 11:01 ` Amir Goldstein
2021-03-17 11:42 ` Jan Kara [this message]
2021-03-17 12:19 ` Amir Goldstein
2021-03-17 17:45 ` Christian Brauner
2021-03-17 19:14 ` Amir Goldstein
2021-03-18 14:31 ` Christian Brauner
2021-03-18 16:48 ` Amir Goldstein
2021-03-19 13:40 ` Christian Brauner
2021-03-19 14:21 ` Amir Goldstein
2021-03-20 12:57 ` Amir Goldstein
2021-03-22 12:44 ` Amir Goldstein
2021-03-22 16:28 ` Christian Brauner
2021-03-22 17:22 ` Amir Goldstein
2021-03-24 13:57 ` Amir Goldstein
2021-03-24 14:32 ` Christian Brauner
2021-03-24 15:05 ` Amir Goldstein
2021-03-24 16:28 ` Christian Brauner
2021-03-24 17:07 ` Amir Goldstein
2021-03-25 11:12 ` Christian Brauner
2021-03-25 15:31 ` Amir Goldstein
2021-03-28 14:58 ` Amir Goldstein
2021-03-18 15:44 ` Jan Kara
2021-03-18 17:07 ` Amir Goldstein
2021-03-18 18:40 ` Christian Brauner
2021-03-22 18:38 ` Amir Goldstein
2021-03-24 11:48 ` Jan Kara
2021-03-24 15:50 ` Amir Goldstein
2021-03-25 13:49 ` Jan Kara
2021-03-25 15:05 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210317114207.GB2541@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=christian.brauner@ubuntu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).