linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).