diff options
author | Eric W. Biederman <ebiederm@xmission.com> | 2014-12-02 18:27:26 (GMT) |
---|---|---|
committer | Eric W. Biederman <ebiederm@xmission.com> | 2014-12-12 00:06:36 (GMT) |
commit | 9cc46516ddf497ea16e8d7cb986ae03a0f6b92f8 (patch) | |
tree | d996dd9c6d422e723af0da786add936bd7ec1c91 /net/hsr | |
parent | f0d62aec931e4ae3333c797d346dc4f188f454ba (diff) | |
download | linux-9cc46516ddf497ea16e8d7cb986ae03a0f6b92f8.tar.xz |
userns: Add a knob to disable setgroups on a per user namespace basis
- Expose the knob to user space through a proc file /proc/<pid>/setgroups
A value of "deny" means the setgroups system call is disabled in the
current processes user namespace and can not be enabled in the
future in this user namespace.
A value of "allow" means the segtoups system call is enabled.
- Descendant user namespaces inherit the value of setgroups from
their parents.
- A proc file is used (instead of a sysctl) as sysctls currently do
not allow checking the permissions at open time.
- Writing to the proc file is restricted to before the gid_map
for the user namespace is set.
This ensures that disabling setgroups at a user namespace
level will never remove the ability to call setgroups
from a process that already has that ability.
A process may opt in to the setgroups disable for itself by
creating, entering and configuring a user namespace or by calling
setns on an existing user namespace with setgroups disabled.
Processes without privileges already can not call setgroups so this
is a noop. Prodcess with privilege become processes without
privilege when entering a user namespace and as with any other path
to dropping privilege they would not have the ability to call
setgroups. So this remains within the bounds of what is possible
without a knob to disable setgroups permanently in a user namespace.
Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Diffstat (limited to 'net/hsr')
0 files changed, 0 insertions, 0 deletions