With respect to cgroups version 1, CAP_SYS_ADMIN in the user
namespace allows only *named* hierarchies to be mounted (and
not hierarchies that have a controller).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
List the mount operations permitted by CAP_SYS_ADMIN in a
noninitial userns.
See https://bugzilla.kernel.org/show_bug.cgi?id=120671
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Having privilege in a user NS only allows privileged
operations on resources governed by that user NS. Many
privileged operations relate to resources that have no
association with any namespace type, and only processes
with privilege in the initial user NS can perform those
operations.
See https://bugzilla.kernel.org/show_bug.cgi?id=120671
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add a concrete example of how the kernel checks capabilities in
an associated user namespace when a process attempts a privileged
operation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid listing all namespace types in a couple of places,
since such a list is subject to bit rot as the number
of namespace types grows.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
No (intentional) changes to factual description, but the
restructured text is hopefully easier to grasp.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
No (intentional) change to the facts, but this restructuring
should make the meaning easier to grasp.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It makes sense to have the description of this file
in the general discussion of user namespaces.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Files with access permissions such as rwx---rwx give fewer
permissions to their group then they do to everyone else. Which
means dropping groups with setgroups(0, NULL) actually grants a
process privileges.
The unprivileged setting of gid_map turned out not to be safe
after this change. Privileged setting of gid_map can be
interpreted as meaning yes it is ok to drop groups. [ Eric
additionally noted: Setting of gid_map with privilege has been
clarified to mean that dropping groups is ok. This allows
existing programs that set gid_map with privilege to work
without changes. That is, newgidmap(1) continues to work
unchanged.]
To prevent this problem and future problems, user namespaces were
changed in such a way as to guarantee a user can not obtain
credentials without privilege that they could not obtain without
the help of user namespaces.
This meant testing the effective user ID and not the filesystem
user ID, as setresuid(2) and setregid(2) allow setting any process
UID or GID (except the supplementary groups) to the effective ID.
Furthermore, to preserve in some form the useful applications
that have been setting gid_map without privilege, the file
/proc/[pid]/setgroups was added to allow disabling setgroups(2).
With setgroups(2) permanently disabled in a user namespace, it
again becomes safe to allow writes to gid_map without privilege.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As at Linux 3.18, the limit is still five lines, so mention the
more recent kernel version in the text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk