From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH v2 00/10] userns: sysctl limits for namespaces Date: Tue, 26 Jul 2016 10:14:06 -0500 Message-ID: <877fc8tosh.fsf@x220.int.ebiederm.org> References: <8737n5dscy.fsf@x220.int.ebiederm.org> <87d1m754jc.fsf@x220.int.ebiederm.org> <94b608ae-1d06-5c41-cbd5-94e663a2163a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <94b608ae-1d06-5c41-cbd5-94e663a2163a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Michael Kerrisk's message of "Tue, 26 Jul 2016 12:27:59 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Michael Kerrisk (man-pages)" Cc: Kees Cook , netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andy Lutomirski , Seth Forshee , Nikolay Borisov , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jann Horn List-Id: containers.vger.kernel.org "Michael Kerrisk (man-pages)" writes: > Hello Eric, > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for sandboxes to limit the attack surface from >> namespaces. >> >> The maximum sane case I can imagine is if every process is a fat >> process, so I set the maximum number of namespaces to the maximum >> number of threads. >> >> I make these limits recursive and per user namespace so that a >> usernamespace root can reduce the limits further. If a user namespace >> root raises the limit the limit in the parent namespace will be honored. >> >> I have cut this implementation to the bare minimum needed to achieve >> these objectives. >> >> Does anyone know if there is a proper error code to return for resource >> limit exceeded? I am currently using -EUSERS or -ENFILE but both of >> those feel a little wrong. > > ENFILE certainly seems weird. I suppose my first question is: why two > different errors? EUSERS was there in the user namespace case for this condition (well nesting depth but same principle) so it made sense to start with. But too many users doesn't really make sense. ENFILE is actually slightly less insane. It actually is about hitting a resource limit, and seemed the most generic catchall we had. > Some alternatives you might want to consider: E2BIG, EOVERFLOW, > or (maybe) ERANGE. My problem with those is typically those are about the values in fields, not about creating too many things. So those really don't feel right. EACCESS or EPERM might be better but those are very very generic. I really want ETOOMANY or something like that. I am actually surprised given how common this pattern is, and the fact that rlimits have existed forever, that we don't have a resource limit exceeded error code. I suppose it might be worth looking at Posix to see if they have any suggestions. Perhaps it may even be time to add an appropriate error code to the list. Not the most important thing out of this patch series but something worth looking at. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757100AbcGZP1l (ORCPT ); Tue, 26 Jul 2016 11:27:41 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:38233 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754641AbcGZP1i (ORCPT ); Tue, 26 Jul 2016 11:27:38 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Michael Kerrisk \(man-pages\)" Cc: Linux Containers , Andy Lutomirski , Jann Horn , Kees Cook , Nikolay Borisov , "Serge E. Hallyn" , Seth Forshee , linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org References: <8737n5dscy.fsf@x220.int.ebiederm.org> <87d1m754jc.fsf@x220.int.ebiederm.org> <94b608ae-1d06-5c41-cbd5-94e663a2163a@gmail.com> Date: Tue, 26 Jul 2016 10:14:06 -0500 In-Reply-To: <94b608ae-1d06-5c41-cbd5-94e663a2163a@gmail.com> (Michael Kerrisk's message of "Tue, 26 Jul 2016 12:27:59 +0200") Message-ID: <877fc8tosh.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bS4GG-0001nk-Cm;;;mid=<877fc8tosh.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19jP/7cbGW0TeO+zxWbisJ4lH1FfunrB4A= X-SA-Exim-Connect-IP: 67.3.204.119 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 * 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 * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Michael Kerrisk \(man-pages\)" X-Spam-Relay-Country: X-Spam-Timing: total 292 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 3.7 (1.3%), b_tie_ro: 2.7 (0.9%), parse: 0.76 (0.3%), extract_message_metadata: 5 (1.7%), get_uri_detail_list: 1.88 (0.6%), tests_pri_-1000: 5.0 (1.7%), tests_pri_-950: 1.50 (0.5%), tests_pri_-900: 1.18 (0.4%), tests_pri_-400: 25 (8.6%), check_bayes: 24 (8.1%), b_tokenize: 8 (2.6%), b_tok_get_all: 9 (2.9%), b_comp_prob: 2.5 (0.9%), b_tok_touch_all: 2.4 (0.8%), b_finish: 0.75 (0.3%), tests_pri_0: 234 (80.2%), check_dkim_signature: 0.58 (0.2%), check_dkim_adsp: 4.3 (1.5%), tests_pri_500: 4.6 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 00/10] userns: sysctl limits for namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -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 "Michael Kerrisk (man-pages)" writes: > Hello Eric, > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for sandboxes to limit the attack surface from >> namespaces. >> >> The maximum sane case I can imagine is if every process is a fat >> process, so I set the maximum number of namespaces to the maximum >> number of threads. >> >> I make these limits recursive and per user namespace so that a >> usernamespace root can reduce the limits further. If a user namespace >> root raises the limit the limit in the parent namespace will be honored. >> >> I have cut this implementation to the bare minimum needed to achieve >> these objectives. >> >> Does anyone know if there is a proper error code to return for resource >> limit exceeded? I am currently using -EUSERS or -ENFILE but both of >> those feel a little wrong. > > ENFILE certainly seems weird. I suppose my first question is: why two > different errors? EUSERS was there in the user namespace case for this condition (well nesting depth but same principle) so it made sense to start with. But too many users doesn't really make sense. ENFILE is actually slightly less insane. It actually is about hitting a resource limit, and seemed the most generic catchall we had. > Some alternatives you might want to consider: E2BIG, EOVERFLOW, > or (maybe) ERANGE. My problem with those is typically those are about the values in fields, not about creating too many things. So those really don't feel right. EACCESS or EPERM might be better but those are very very generic. I really want ETOOMANY or something like that. I am actually surprised given how common this pattern is, and the fact that rlimits have existed forever, that we don't have a resource limit exceeded error code. I suppose it might be worth looking at Posix to see if they have any suggestions. Perhaps it may even be time to add an appropriate error code to the list. Not the most important thing out of this patch series but something worth looking at. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH v2 00/10] userns: sysctl limits for namespaces Date: Tue, 26 Jul 2016 10:14:06 -0500 Message-ID: <877fc8tosh.fsf@x220.int.ebiederm.org> References: <8737n5dscy.fsf@x220.int.ebiederm.org> <87d1m754jc.fsf@x220.int.ebiederm.org> <94b608ae-1d06-5c41-cbd5-94e663a2163a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Kees Cook , netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andy Lutomirski , Seth Forshee , Nikolay Borisov , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jann Horn To: "Michael Kerrisk \(man-pages\)" Return-path: In-Reply-To: <94b608ae-1d06-5c41-cbd5-94e663a2163a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Michael Kerrisk's message of "Tue, 26 Jul 2016 12:27:59 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: netdev.vger.kernel.org "Michael Kerrisk (man-pages)" writes: > Hello Eric, > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for sandboxes to limit the attack surface from >> namespaces. >> >> The maximum sane case I can imagine is if every process is a fat >> process, so I set the maximum number of namespaces to the maximum >> number of threads. >> >> I make these limits recursive and per user namespace so that a >> usernamespace root can reduce the limits further. If a user namespace >> root raises the limit the limit in the parent namespace will be honored. >> >> I have cut this implementation to the bare minimum needed to achieve >> these objectives. >> >> Does anyone know if there is a proper error code to return for resource >> limit exceeded? I am currently using -EUSERS or -ENFILE but both of >> those feel a little wrong. > > ENFILE certainly seems weird. I suppose my first question is: why two > different errors? EUSERS was there in the user namespace case for this condition (well nesting depth but same principle) so it made sense to start with. But too many users doesn't really make sense. ENFILE is actually slightly less insane. It actually is about hitting a resource limit, and seemed the most generic catchall we had. > Some alternatives you might want to consider: E2BIG, EOVERFLOW, > or (maybe) ERANGE. My problem with those is typically those are about the values in fields, not about creating too many things. So those really don't feel right. EACCESS or EPERM might be better but those are very very generic. I really want ETOOMANY or something like that. I am actually surprised given how common this pattern is, and the fact that rlimits have existed forever, that we don't have a resource limit exceeded error code. I suppose it might be worth looking at Posix to see if they have any suggestions. Perhaps it may even be time to add an appropriate error code to the list. Not the most important thing out of this patch series but something worth looking at. Eric