From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: containers@lists.linux-foundation.org, keescook@chromium.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
luto@amacapital.net, seth.forshee@canonical.com, kernel@kyup.com,
linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
jann@thejh.net
Subject: Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.
Date: Mon, 25 Jul 2016 19:44:50 -0500 [thread overview]
Message-ID: <87k2g95it9.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20160725.172406.352408511647766870.davem@davemloft.net> (David Miller's message of "Mon, 25 Jul 2016 17:24:06 -0700 (PDT)")
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Mon, 25 Jul 2016 19:02:01 -0500
>
>> Which means this change gets has to wait for next cycle.
>
> Ok.
For clarity I intend to merge these changes through the userns tree,
when the issues are resolved.
I Cc'd netdev as there is a limit on the number of network namespaces in
this set which may be of interest to networking folks.
I expect there will be some follow on about adding sanity checking
limits to other kernel data structures like a maximum number of mounts
in a mount namespace, and perhaps a maximum number of routes in a
network namespace.
User namespaces have enabled unprivileged users access to a lot more
data structures and so to catch programs that go crazy we need a lot
more limits. I believe some of those limits make sense per namespace.
As it is easy in some cases to say any more than Y number of those
per namespace is excessive. For example a limit of 1,000,000 ipv4
routes per network namespaces is a sanity check as there are
currently 621,649 ipv4 prefixes advertized in bgp.
But that is something to worry about after the merge window.
Eric
next prev parent reply other threads:[~2016-07-26 0:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8737n5dscy.fsf@x220.int.ebiederm.org>
2016-07-21 16:39 ` [PATCH v2 00/10] userns: sysctl limits for namespaces Eric W. Biederman
2016-07-21 16:40 ` [PATCH v2 01/10] sysctl: Stop implicitly passing current into sysctl_table_root.lookup Eric W. Biederman
2016-07-21 16:40 ` [PATCH v2 02/10] userns: Add per user namespace sysctls Eric W. Biederman
2016-07-26 0:02 ` Eric W. Biederman
2016-07-26 0:24 ` David Miller
2016-07-26 0:44 ` Eric W. Biederman [this message]
2016-07-26 2:58 ` David Miller
2016-07-26 4:00 ` Eric W. Biederman
2016-07-21 16:40 ` [PATCH v2 03/10] userns: Add a limit on the number of user namespaces Eric W. Biederman
2016-07-25 23:05 ` Serge E. Hallyn
2016-07-21 16:40 ` [PATCH v2 04/10] userns: Generalize the user namespace count into ucount Eric W. Biederman
2016-07-25 23:09 ` Serge E. Hallyn
2016-07-21 16:40 ` [PATCH v2 05/10] pidns: Add a limit on the number of pid namespaces Eric W. Biederman
2016-07-25 23:09 ` Serge E. Hallyn
2016-07-21 16:40 ` [PATCH v2 06/10] utsns: Add a limit on the number of uts namespaces Eric W. Biederman
2016-07-25 23:09 ` Serge E. Hallyn
2016-07-21 16:40 ` [PATCH v2 07/10] ipcns: Add a limit on the number of ipc namespaces Eric W. Biederman
2016-07-25 23:10 ` Serge E. Hallyn
2016-07-21 16:40 ` [PATCH v2 08/10] cgroupns: Add a limit on the number of cgroup namespaces Eric W. Biederman
2016-07-25 23:12 ` Serge E. Hallyn
2016-07-21 16:40 ` [PATCH v2 09/10] netns: Add a limit on the number of net namespaces Eric W. Biederman
2016-07-25 23:13 ` Serge E. Hallyn
2016-07-26 6:01 ` Andrei Vagin
2016-07-26 20:00 ` Eric W. Biederman
2016-07-21 16:40 ` [PATCH v2 10/10] mntns: Add a limit on the number of mount namespaces Eric W. Biederman
2016-07-25 23:15 ` Serge E. Hallyn
2016-07-22 13:33 ` [PATCH v2 00/10] userns: sysctl limits for namespaces Colin Walters
2016-07-22 18:45 ` Eric W. Biederman
2016-07-22 21:46 ` Kees Cook
2016-07-23 2:11 ` Eric W. Biederman
2016-07-26 10:27 ` Michael Kerrisk (man-pages)
2016-07-26 15:14 ` Eric W. Biederman
2016-07-26 10:30 ` Michael Kerrisk (man-pages)
2016-07-26 15:06 ` Eric W. Biederman
2016-07-26 16:52 ` Kees Cook
2016-07-26 17:29 ` Michael Kerrisk (man-pages)
2016-07-26 20:44 ` Kees Cook
2016-08-08 21:16 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k2g95it9.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=containers@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=kernel@kyup.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=seth.forshee@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox