LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: email@example.com (Eric W. Biederman)
To: Alban Crequy <firstname.lastname@example.org>
Cc: Alban Crequy <email@example.com>, Dongsu Park <firstname.lastname@example.org>,
Iago Lopez Galeiras <email@example.com>,
Stephen J Day <firstname.lastname@example.org>,
Michael Crosby <email@example.com>,
Jess Frazelle <firstname.lastname@example.org>,
Akihiro Suda <email@example.com>,
Aleksa Sarai <firstname.lastname@example.org>, Daniel J Walsh <email@example.com>,
Alexander Viro <firstname.lastname@example.org>,
Subject: Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc mounts when not fully visible
Date: Wed, 04 Apr 2018 09:45:43 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (Alban Crequy's message of "Wed, 4 Apr 2018 13:53:11 +0200")
Alban Crequy <email@example.com> writes:
> Since Linux v4.2 with commit 1b852bceb0d1 ("mnt: Refactor the logic for
> mounting sysfs and proc in a user namespace"), new mounts of proc or
> sysfs in non init userns are only allowed when there is at least one
> fully-visible proc or sysfs mount.
> This is to enforce that proc/sysfs files masked by a mount are still
> masked in a new mount in a unprivileged userns. The locked mount logic
> for bind mounts (has_locked_children()) was not enough in the case of
> proc/sysfs new mounts because some files in proc (/proc/kcore) exist as
> a singleton rather than being owned by a specific proc mount.
> Unfortunately, this blocks me from using userns from within a Docker
> container because Docker containers mask entries such as /proc/kcore. My
> use case is to build container images with arbitrary commands (such as
> using "RUN" commands in Dockerfiles) without privileges and from within
> a Docker container. Those arbitrary commands could be shell scripts that
> require /proc.
This is an understandable problem. /proc/kcore is a file that policy
has a very reasonable right to make inaccessible. Allowing unprivileged
users to bypass the policy setup by root is not ok, and is the whole
point of the restrictions.
I need to hear why you can't fix Docker. Why your subcommand needs to
mount proc in the first place. Neither have been mentioned. So far
this looks like ``my sysadmin told me no, can I have a kernel patch to
get around that''. Not something I support at all.
Before we get a kernel change for something like this there need to be
clear evidence this raises to the point of something that is really
going to be used and will have multiple users, and the proposal will
be simple and maintainble.
Hiding files in /proc simply because they were mounted over in the
parent proc does not qualify as simple or maintainble by any means.
Way too much mixing of the layers. Needing to read from the parent
proc to find which files were already hidden makes this doubly complex.
Files like /proc/kcore can not be hidden always and automatically
because their attributes can change so they may reasonably be made
available to users who are not the global root.
The only option I have seen proposed that might qualify as something
general purpose and simple is a new filesystem that is just the process
directories of proc. As there would in essence be no files that would
need restrictions it would be safe to allow anyone to mount without
> The following commands show my problem:
> $ sudo docker run -ti --rm --cap-add=SYS_ADMIN busybox sh -c 'unshare -U -r -p -m -f mount -t proc proc /home && echo ok'
> mount: permission denied (are you root?)
> $ sudo docker run -ti --rm --cap-add=SYS_ADMIN busybox sh -c 'mkdir -p /unmasked-proc && mount -t proc proc /unmasked-proc && unshare -U -r -p -m -f mount -t proc proc /home && echo ok'
Actually this does not show your problem because it does not reveal why
you need to mount proc.
That is a ``Doctor it hurts when I do this'' example where the Doctor
will reasonably tell you ``Don't do that then''.
> For my use case, I will need to support at least the following entries:
> $ sudo docker run -ti --rm busybox sh -c 'mount|grep /proc/'
> proc on /proc/asound type proc (ro,nosuid,nodev,noexec,relatime)
> proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime)
> proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime)
> proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime)
> proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
> proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
> tmpfs on /proc/kcore type tmpfs (rw,context="...",nosuid,mode=755)
> tmpfs on /proc/latency_stats type tmpfs (rw,context="...",nosuid,mode=755)
> tmpfs on /proc/timer_list type tmpfs (rw,context="...",nosuid,mode=755)
> tmpfs on /proc/sched_debug type tmpfs (rw,context="...",nosuid,mode=755)
> tmpfs on /proc/scsi type tmpfs (ro,seclabel,relatime)
It looks like a cruft free cousin of proc that is just processes would
be applicable to your usecase.
next prev parent reply other threads:[~2018-04-04 14:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-04 11:53 Alban Crequy
2018-04-04 14:45 ` Eric W. Biederman [this message]
2018-04-04 15:34 ` Aleksa Sarai
2018-04-04 18:42 ` Serge E. Hallyn
2018-04-04 22:02 ` Eric W. Biederman
2018-04-05 14:19 ` Christian Brauner
2018-04-13 22:41 ` Djalal Harouni
2018-04-16 14:16 ` Alexey Gladkov
2018-04-04 17:45 Alexey Dobriyan
2018-04-04 17:49 Alexey Dobriyan
2018-04-04 23:59 ` Eric W. Biederman
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc mounts when not fully visible' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).