Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755858AbbBUH5W (ORCPT ); Sat, 21 Feb 2015 02:57:22 -0500 Received: from mail-wi0-f175.google.com ([209.85.212.175]:63630 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755820AbbBUH5O (ORCPT ); Sat, 21 Feb 2015 02:57:14 -0500 Message-ID: <54E83A55.9080408@gmail.com> Date: Sat, 21 Feb 2015 08:57:09 +0100 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Eric W. Biederman" CC: mtk.manpages@gmail.com, Linux Containers , Josh Triplett , Andrew Morton , Kees Cook , Linux API , linux-man , "linux-kernel@vger.kernel.org" , LSM , Casey Schaufler , "Serge E. Hallyn" , Richard Weinberger , Kenton Varda , stable , Andy Lutomirski Subject: Re: [PATCH 1/2] proc.5: Document /proc/[pid]/setgroups References: <52e0643bd47b1e5c65921d6e00aea1f724bb510a.1417281801.git.luto@amacapital.net> <87ppbtn4mv.fsf@x220.int.ebiederm.org> <87a92xn2io.fsf@x220.int.ebiederm.org> <87r3w8liw4.fsf@x220.int.ebiederm.org> <87iohklfvj.fsf_-_@x220.int.ebiederm.org> <87fvcok11h.fsf_-_@x220.int.ebiederm.org> <971ad3f6-90fd-4e3f-916c-8988af3c826d@email.android.com> <87wq5zf83t.fsf@x220.int.ebiederm.org> <87iohh3c9c.fsf@x220.int.ebiederm.org> <8761dh3b7k.fsf_-_@x220.int.ebiederm.org> <878uicy1r9.fsf_-_@x220.int.ebiederm.org> <87vblg1qme.fsf@x220.int.ebiederm.org> <54CF9995.1050409@gmail.com> <8761b8lfoz.fsf@x220.int.ebiederm.org> <54DCB059.2020305@gmail.com> In-Reply-To: <54DCB059.2020305@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6418 Lines: 162 Hi Eric, Ping! Cheers, Michael On 02/12/2015 02:53 PM, Michael Kerrisk (man-pages) wrote: > Hello Eric, > > On 02/11/2015 02:51 PM, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> Hi Eric, >>> >>> Ping! >>> >>> Cheers, >>> >>> Michael >> >> My apologies. You description wasn't wrong but it may be a bit >> misleading, explanation below. You will have to figure out how to work >> that into your proposed text. >> >>> On 2 February 2015 at 16:36, Michael Kerrisk (man-pages) >>> wrote: >>>> [Adding Josh to CC in case he has anything to add.] >>>> >>>> On 12/12/2014 10:54 PM, Eric W. Biederman wrote: >>>>> >>>>> Signed-off-by: Eric W. Biederman >>>>> --- >>>>> man5/proc.5 | 15 +++++++++++++++ >>>>> 1 file changed, 15 insertions(+) >>>>> >>>>> diff --git a/man5/proc.5 b/man5/proc.5 >>>>> index 96077d0dd195..d661e8cfeac9 100644 >>>>> --- a/man5/proc.5 >>>>> +++ b/man5/proc.5 >>>>> @@ -1097,6 +1097,21 @@ are not available if the main thread has already terminated >>>>> .\" Added in 2.6.9 >>>>> .\" CONFIG_SCHEDSTATS >>>>> .TP >>>>> +.IR /proc/[pid]/setgroups " (since Linux 3.19-rc1)" >>>>> +This file reports >>>>> +.BR allow >>>>> +if the setgroups system call is allowed in the current user namespace. >>>>> +This file reports >>>>> +.BR deny >>>>> +if the setgroups system call is not allowed in the current user namespace. >>>>> +This file may be written to with values of >>>>> +.BR allow >>>>> +and >>>>> +.BR deny >>>>> +before >>>>> +.IR /proc/[pid]/gid_map >>>>> +is written to (enabling setgroups) in a user namespace. >>>>> +.TP >>>>> .IR /proc/[pid]/smaps " (since Linux 2.6.14)" >>>>> This file shows memory consumption for each of the process's mappings. >>>>> (The >>>> >>>> Hi Eric, >>>> >>>> Thanks for this patch. I applied it, and then tried to work in >>>> quite a few other details gleaned from the source code and commit >>>> message, and Jon Corbet's article at http://lwn.net/Articles/626665/. >>>> Could you please let me know if the following is correct: >> >> It is close but it may be misleading. >> >>>> /proc/[pid]/setgroups (since Linux 3.19) >>>> This file displays the string "allow" if processes in >>>> the user namespace that contains the process pid are >>>> permitted to employ the setgroups(2) system call, and >>>> "deny" if setgroups(2) is not permitted in that user >>>> namespace. >> >> With the caveat that when gid_map is not set that setgroups is also not >> allowed. > > Okay -- Iadded that point. > >>>> A privileged process (one with the CAP_SYS_ADMIN capa‐ >>>> bility in the namespace) may write either of the strings >>>> "allow" or "deny" to this file before writing a group ID >>>> mapping for this user namespace to the file >>>> /proc/[pid]/gid_map. Writing the string "deny" prevents >>>> any process in the user namespace from employing set‐ >>>> groups(2). >> >> Or more succintly. You are allowed to write to /proc/[pid]/setgroups >> when calling setgroups is not allowed because gid_map is unset. This >> ensures we do not have any transitions from a state where setgroups >> is allowed to a state where setgroups is denied. There are only >> transitions from setgroups not-allowed to setgroups allowed. > > And I've worked in the above point, rewording a bit along the way. > So, how does the following look (only the first two paragraphs have > changed)? > > /proc/[pid]/setgroups (since Linux 3.19) > This file displays the string "allow" if processes in > the user namespace that contains the process pid are > permitted to employ the setgroups(2) system call, and > "deny" if setgroups(2) is not permitted in that user > namespace. (Note, however, that calls to setgroups(2) > are also not permitted if /proc/[pid]/gid_map has not > yet been set.) > > A privileged process (one with the CAP_SYS_ADMIN capa‐ > bility in the namespace) may write either of the strings > "allow" or "deny" to this file before writing a group ID > mapping for this user namespace to the file > /proc/[pid]/gid_map. Writing the string "deny" prevents > any process in the user namespace from employing set‐ > groups(2). In other words, it is permitted to write to > /proc/[pid]/setgroups so long as calling setgroups(2) is > not allowed because /proc/[pid]gid_map has not been set. > This ensures that a process cannot transition from a > state where setgroups(2) is allowed to a state where > setgroups(2) is denied; a process can only trabsition > from setgroups(2) being disallowed to setgroups(2) being > allowed. > > The default value of this file in the initial user > namespace is "allow". > > Once /proc/[pid]/gid_map has been written to (which has > the effect of enabling setgroups(2) in the user names‐ > pace), it is no longer possible to deny setgroups(2) by > writing to /proc/[pid]/setgroups. > > A child user namespace inherits the /proc/[pid]/gid_map > setting from its parent. > > If the setgroups file has the value "deny", then the > setgroups(2) system call can't subsequently be reenabled > (by writing "allow" to the file) in this user namespace. > This restriction also propagates down to all child user > namespaces of this user namespace. > > Cheers, > > Michael > > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/