linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
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>
Subject: Re: [PATCH v2 0/2] unprivileged fanotify listener
Date: Thu, 18 Mar 2021 19:40:37 +0100	[thread overview]
Message-ID: <20210318184037.k7y3nrk3naktuwvl@wittgenstein> (raw)
In-Reply-To: <CAOQ4uxhpB+1iFSSoZy2NuF2diL=8uJ-j8JJVNnujqtphW147cw@mail.gmail.com>

On Thu, Mar 18, 2021 at 07:07:00PM +0200, Amir Goldstein wrote:
> > > That may change when systemd home dirs feature starts to use idmapped
> > > mounts. Being able to watch the user's entire home directory is a big
> > > win already.
> >
> > Do you mean that home directory would be an extra mount with userns in
> > which the user has CAP_SYS_ADMIN so he'd be able to watch subtrees on that
> > mount?
> >
> 
> That is what I meant.
> My understanding of the systemd-homed use case for idmapped mounts is
> that the user has CAP_SYS_ADMIN is the mapped userns, but I may be wrong.

systemd can simply create a new userns with the uid/gid of the target
user effectively delegating it (That's independent of actually writing a
uid gid mapping for the userns which will be done with privileges.) and
then attach it to that mount for the user.
Mine and Lennart's idea there so far has been that the creation would
likely be done by the user's session at login time

brauner     1346  0.0  0.0  20956  8512 ?        Ss   Mar03   0:03 /lib/systemd/systemd --user

and systemd as root would then take care of writing the mapping to the
userns and then attaching it to the mount. (I'll see Lennart in the next
few days and see what works best and once we're ready start a discussion
somwhere on a public list, I would suggest.)

(If systemd doesn't want a user to be able to monitor a mnt it can
simply create a userns with a different uid/gid but with the relevant
mapping. This was what my earlier point was about "blocking a user from
creating a subtree watch".)

Christian

  reply	other threads:[~2021-03-18 18:41 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
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 [this message]
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=20210318184037.k7y3nrk3naktuwvl@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --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).