From: Lord Glauber Costa of Sealand <glommer@parallels.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: <linux-fsdevel@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
<linux-kernel@vger.kernel.org>, Michael Kerrisk <mtk@lwn.net>
Subject: Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Date: Mon, 28 Jan 2013 20:37:21 +0400 [thread overview]
Message-ID: <5106A941.6060403@parallels.com> (raw)
In-Reply-To: <87k3qxs2ko.fsf@xmission.com>
On 01/28/2013 08:19 PM, Eric W. Biederman wrote:
> Lord Glauber Costa of Sealand <glommer@parallels.com> writes:
>
>> On 01/28/2013 12:14 PM, Eric W. Biederman wrote:
>>> Lord Glauber Costa of Sealand <glommer@parallels.com> writes:
>>>
>>>> I just saw in a later patch of yours that your concern here seems not
>>>> limited to backed ram by tmpfs, but with things like the internal
>>>> structures for userns , to avoid patterns in the form: 'for (;;)
>>>> unshare(...)'
>>>>
>>>> Humm, it does seem sensible. The kernel memory controller aims to
>>>> prevent exactly things like that. But they all exist already before
>>>> userns: there are destructive patterns like that with sockets, dentries,
>>>> processes, and pretty much every other resource in the kernel. So
>>>> Although the recommendation per-se makes sense, I am wondering if it is
>>>> worth it to mention anything in the user_ns config?
>>>
>>> The config might be overkill. However I have already gotten bug reports
>>> about there being no limits.
>>>
>>> So someone needs to stop and connect the dots and say:
>> Absolutely, and I am all for it
>>
>>> "If you care this is what you can do."
>>
>> How about we say it, then?
>>
>> The current text in quite cryptic in this aspect, in the sense that it
>> doesn't give enough information for standard people about what are the
>> problems involved.
>>
>> Of course, maybe the Kconfig text is not the best place for having all
>> the info: but don't we have some place in Documentation/ where we could
>> put this, and then refer people there from Kconfig ?
>
> At this point I have written the best text I can.
>
> Please feel free to look at my tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next
>
Will do soon, thanks for your effort.
> and send me an patch on top of that to improve the wording.
>
> At this point I have done my best to connect the dots for people who
> care, that the memory control group is what they need to limit what
> people can do with user namespaces.
>
> My hope is that there is at least a passing mention in the next user
> namespace article on lwn.
It would definitely be helpful. Let's hope someone from there is reading! =)
>
> For two pieces of software that were designed to complement each other
> I find it a bit surprising how many people (including myself) need the
> connection made that memory control groups and user namespaces should go
> together.
Well, I've manifested many times in here that I am less than satisfied
about the fact that the connection between namespaces and cgroups are so
loose. There are many situations, like virtualizing the proc files and
friends where I believe we could benefit from having the information
about whether or not cgroups and namespaces are used at the same time.
But since after considering a lot of alternatives, I could never come up
with one that were really clean, I guess just communicating it
extensively is the best we can do so far.
next prev parent reply other threads:[~2013-01-28 16:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-26 2:15 [PATCH review 0/6] miscelaneous user namespace patches Eric W. Biederman
2013-01-26 2:19 ` [PATCH review 1/6] userns: Avoid recursion in put_user_ns Eric W. Biederman
2013-01-26 20:58 ` Serge E. Hallyn
2013-01-28 14:51 ` Vasily Kulikov
2013-01-28 16:34 ` Eric W. Biederman
2013-01-26 2:21 ` [PATCH review 2/6] userns: Allow any uid or gid mappings that don't overlap Eric W. Biederman
2013-01-26 21:08 ` Serge E. Hallyn
2013-01-28 14:28 ` Aristeu Rozanski
2013-01-28 14:41 ` Lord Glauber Costa of Sealand
2013-01-28 15:12 ` Aristeu Rozanski
2013-01-26 2:22 ` [PATCH review 3/6] userns: Recommend use of memory control groups Eric W. Biederman
2013-01-26 21:13 ` Serge E. Hallyn
2013-01-27 6:19 ` Eric W. Biederman
2013-01-28 7:37 ` Lord Glauber Costa of Sealand
2013-01-28 7:50 ` Lord Glauber Costa of Sealand
2013-01-28 8:14 ` Eric W. Biederman
2013-01-28 8:22 ` Lord Glauber Costa of Sealand
2013-01-28 16:19 ` Eric W. Biederman
2013-01-28 16:37 ` Lord Glauber Costa of Sealand [this message]
2013-01-28 17:18 ` Eric W. Biederman
2013-01-28 8:05 ` Eric W. Biederman
2013-01-26 2:23 ` [PATCH review 4/6] userns: Allow the userns root to mount of devpts Eric W. Biederman
2013-01-26 21:22 ` Serge E. Hallyn
2013-01-26 2:26 ` [PATCH review 5/6] userns: Allow the userns root to mount ramfs Eric W. Biederman
2013-01-26 21:29 ` Serge E. Hallyn
2013-01-27 6:09 ` Eric W. Biederman
2013-01-27 18:23 ` Serge E. Hallyn
2013-01-27 18:23 ` Serge E. Hallyn
2013-01-26 2:26 ` [PATCH review 6/6] userns: Allow the userns root to mount tmpfs Eric W. Biederman
2013-01-27 18:23 ` Serge E. Hallyn
2013-01-28 1:28 ` Gao feng
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=5106A941.6060403@parallels.com \
--to=glommer@parallels.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk@lwn.net \
/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;
as well as URLs for NNTP newsgroup(s).