From: Andy Lutomirski <luto@kernel.org>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: "Stas Sergeev" <stsp2@yandex.ru>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-kernel@vger.kernel.org,
"Stefan Metzmacher" <metze@samba.org>,
"Eric Biederman" <ebiederm@xmission.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Andy Lutomirski" <luto@kernel.org>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>, "Jeff Layton" <jlayton@kernel.org>,
"Chuck Lever" <chuck.lever@oracle.com>,
"Alexander Aring" <alex.aring@gmail.com>,
"David Laight" <David.Laight@aculab.com>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Christian Göttsche" <cgzones@googlemail.com>
Subject: Re: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2()
Date: Mon, 6 May 2024 10:34:16 -0700 [thread overview]
Message-ID: <CALCETrUZp2P1PXwJeL7ryda_qSLGsgHf5X0Zpw8piiT58k-cYg@mail.gmail.com> (raw)
In-Reply-To: <CALCETrU2VwCF-o7E5sc8FN_LBs3Q-vNMBf7N4rm0PAWFRo5QWw@mail.gmail.com>
On Mon, May 6, 2024 at 10:29 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> Replying to a couple emails at once...
>
> On Mon, May 6, 2024 at 12:14 AM Aleksa Sarai <cyphar@cyphar.com> wrote:
> > I also find it somewhat amusing that this proposal is to basically give
> > up on multi-user permissions for this one directory tree because it's
> > too annoying to deal with. In that case, isn't chmod 777 a simpler
> > solution? (I'm being a bit flippant, of course there is a difference,
> > but the net result is that all users in the container would have the
> > same permissions with all of the fun issues that implies.)
> >
> > In short, AFAICS idmapped mounts pretty much solve this problem (minus
> > the ability to collapse users, which I suspect is not a good idea in
> > general)?
> >
>
> With my kernel hat on, maybe I agree. But with my *user* hat on, I
> think I pretty strongly disagree. Look, idmapis lousy for
> unprivileged use:
>
> $ install -m 0700 -d test_directory
> $ echo 'hi there' >test_directory/file
> $ podman run -it --rm
> --mount=type=bind,src=test_directory,dst=/tmp,idmap [debian-slim]
> # cat /tmp/file
> hi there
>
> <-- Hey, look, this kind of works!
>
> # setpriv --reuid=1 ls /tmp
> ls: cannot open directory '/tmp': Permission denied
>
> <-- Gee, thanks, Linux!
I should add: this is lousy even for privileged use. On a normal
non-containerized system:
$ ls -ld /var/lib/mysql
drwxr-xr-x. 3 mysql mysql 4096 Sep 20 2023 /var/lib/mysql
This makes perfect sense.
But if I want to run mysql in a container in a sane way, my only real
choice is either to trust the container manager quite strongly (so it
only maps this directory into the correct container) or, if I want to
separate out management of this container into its own UID (which is a
good practice), then I'm forced to do some kind of fragile hack like
making a directory only accessible to the correct UID and then
creating a 0777 directory inside it and bind-mounting *that*.
next prev parent reply other threads:[~2024-05-06 17:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 13:33 [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() Stas Sergeev
2024-04-26 13:33 ` [PATCH v5 1/3] fs: reorganize path_openat() Stas Sergeev
2024-04-26 13:33 ` [PATCH v5 2/3] open: add O_CRED_ALLOW flag Stas Sergeev
2024-04-27 2:12 ` kernel test robot
2024-04-26 13:33 ` [PATCH v5 3/3] openat2: add OA2_CRED_INHERIT flag Stas Sergeev
2024-04-28 16:41 ` [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() Andy Lutomirski
2024-04-28 17:39 ` stsp
2024-04-28 19:15 ` stsp
2024-04-28 20:19 ` Andy Lutomirski
2024-04-28 21:14 ` stsp
2024-04-28 21:30 ` Andy Lutomirski
2024-04-28 22:12 ` stsp
2024-04-29 1:12 ` stsp
2024-04-29 9:12 ` Christian Brauner
2024-05-06 7:13 ` Aleksa Sarai
2024-05-06 17:29 ` Andy Lutomirski
2024-05-06 17:34 ` Andy Lutomirski [this message]
2024-05-06 19:34 ` David Laight
2024-05-06 21:53 ` Andy Lutomirski
2024-05-07 7:42 ` Christian Brauner
2024-05-07 20:38 ` Andy Lutomirski
2024-05-08 7:32 ` Christian Brauner
2024-05-08 17:30 ` Andy Lutomirski
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=CALCETrUZp2P1PXwJeL7ryda_qSLGsgHf5X0Zpw8piiT58k-cYg@mail.gmail.com \
--to=luto@kernel.org \
--cc=David.Laight@aculab.com \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=cgzones@googlemail.com \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=metze@samba.org \
--cc=pbonzini@redhat.com \
--cc=serge@hallyn.com \
--cc=stsp2@yandex.ru \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.