aboutsummaryrefslogtreecommitdiff
path: root/block/Kconfig
diff options
context:
space:
mode:
authorEric W. Biederman2014-12-02 12:27:26 -0600
committerEric W. Biederman2014-12-11 18:06:36 -0600
commit9cc46516ddf497ea16e8d7cb986ae03a0f6b92f8 (patch)
treed996dd9c6d422e723af0da786add936bd7ec1c91 /block/Kconfig
parentf0d62aec931e4ae3333c797d346dc4f188f454ba (diff)
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 'block/Kconfig')
0 files changed, 0 insertions, 0 deletions