Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752938AbbBKNyd (ORCPT ); Wed, 11 Feb 2015 08:54:33 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:37480 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbbBKNy2 convert rfc822-to-8bit (ORCPT ); Wed, 11 Feb 2015 08:54:28 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: mtk.manpages@gmail.com Cc: 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 References: <52e0643bd47b1e5c65921d6e00aea1f724bb510a.1417281801.git.luto@amacapital.net> <87h9x5re41.fsf_-_@x220.int.ebiederm.org> <87mw6xpzb0.fsf_-_@x220.int.ebiederm.org> <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> Date: Wed, 11 Feb 2015 07:51:08 -0600 In-Reply-To: (Michael Kerrisk's message of "Wed, 11 Feb 2015 09:01:57 +0100") Message-ID: <8761b8lfoz.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-AID: U2FsdGVkX1+qWZ53u920Yy7odHyoxgsUJcbMRWPbv90= X-SA-Exim-Connect-IP: 70.59.163.10 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.5 XM_Body_Dirty_Words Contains a dirty word * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.1 XMSolicitRefs_0 Weightloss drug X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;mtk.manpages@gmail.com X-Spam-Relay-Country: X-Spam-Timing: total 375 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.9 (0.8%), b_tie_ro: 2.1 (0.6%), parse: 0.76 (0.2%), extract_message_metadata: 13 (3.4%), get_uri_detail_list: 2.1 (0.6%), tests_pri_-1000: 6 (1.5%), tests_pri_-950: 0.96 (0.3%), tests_pri_-900: 0.85 (0.2%), tests_pri_-400: 25 (6.7%), check_bayes: 24 (6.5%), b_tokenize: 7 (2.0%), b_tok_get_all: 10 (2.5%), b_comp_prob: 2.4 (0.6%), b_tok_touch_all: 2.8 (0.7%), b_finish: 0.63 (0.2%), tests_pri_0: 316 (84.2%), tests_pri_500: 8 (2.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 1/2] proc.5: Document /proc/[pid]/setgroups X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4176 Lines: 108 "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. >> 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. >> 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. Eric -- 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/