public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: LXC development mailing-list <lxc-devel@lists.linuxcontainers.org>
Cc: containers@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [lxc-devel] [RFC] Per-user namespace process accounting
Date: Thu, 12 Jun 2014 15:08:43 +0000	[thread overview]
Message-ID: <20140612150842.GC4228@ubuntumail> (raw)
In-Reply-To: <5399BB42.60304@elastichosts.com>

Quoting Alin Dobre (alin.dobre@elastichosts.com):
> On 29/05/14 07:37, Marian Marinov wrote:
> > Hello,
> > 
> > I have the following proposition.
> > 
> > Number of currently running processes is accounted at the root user namespace. The problem I'm facing is that multiple
> > containers in different user namespaces share the process counters.

Most ppl here probably are aware of this, but the previous, never-completed
user namespace implementation provided this and only this.  We (mostly Eric
and I) spent years looking for clean ways to make that implementation, which
had some advantages (including this one), complete.  We did have a few POCs
which worked but were unsatisfying.  The two things which were never convincing
were (a) conversion of all uid checks to be namespace-safe, and (b) storing
namespace identifiers on disk.  (As I say we did have solutions to these, but
not satisfying ones).  These are the two things which the new implementation
address *beautifully*.

> > So if containerX runs 100 with UID 99, containerY should have NPROC limit of above 100 in order to execute any
> > processes with ist own UID 99.
> > 
> > I know that some of you will tell me that I should not provision all of my containers with the same UID/GID maps, but
> > this brings another problem.
> 
> If this matters, we also suffer from the same problem here. So we
> support any implementation that would address it.

ISTM the only reasonable answer here (at least for now) is to make it more
convenient to isolate uid ranges, by providing a way to shift uids at mount
time as has been discussed a bit.

If we go down the route of talking about uid 99 in ns 1 vs uid 99 in ns 2,
then people will also expect isolation at file access time, and we're back
to all the disadvantages of the first userns implementation.

(If someone proves me wrong by suggesting a clean solution, then awesome)

-serge

      reply	other threads:[~2014-06-12 15:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-29  6:37 [RFC] Per-user namespace process accounting Marian Marinov
2014-05-29 10:06 ` Eric W. Biederman
2014-05-29 10:40   ` Marian Marinov
2014-05-29 15:32     ` Serge Hallyn
2014-06-03 17:01       ` Pavel Emelyanov
2014-06-03 17:26         ` Serge Hallyn
2014-06-03 17:39           ` Pavel Emelyanov
2014-06-03 17:47             ` Serge Hallyn
2014-06-03 18:18             ` Eric W. Biederman
2014-06-03 17:54           ` Eric W. Biederman
2014-06-03 21:39             ` Marian Marinov
2014-06-23  4:07               ` Serge E. Hallyn
2014-06-07 21:39             ` James Bottomley
2014-06-08  3:25               ` Eric W. Biederman
2014-06-12 14:37 ` Alin Dobre
2014-06-12 15:08   ` Serge Hallyn [this message]

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=20140612150842.GC4228@ubuntumail \
    --to=serge.hallyn@ubuntu.com \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lxc-devel@lists.linuxcontainers.org \
    /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