All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	LKML <linux-kernel@vger.kernel.org>,
	alan@lxorguk.ukuu.org.uk, morgan@kernel.org, luto@mit.edu,
	kzak@redhat.com, Steve Grubb <sgrubb@redhat.com>
Subject: Re: chroot(2) and bind mounts as non-root
Date: Tue, 20 Dec 2011 16:23:30 -0500	[thread overview]
Message-ID: <1324416210.25566.35.camel@lenny> (raw)
In-Reply-To: <m1ehw1mlcf.fsf@fess.ebiederm.org>

On Sun, 2011-12-18 at 16:55 -0800, Eric W. Biederman wrote:

> I expect by the time this makes it to "out of the box" experiences on
> enterprise distros, useradd and friends will be giving out 1000 or so uids
> to new accounts.

Hmm...how would that work?  Would it be something that would happen at
PAM time, like a module that looks up some file in /etc and says "OK
this uid gets this range" and uploads that to the kernel? 

This whole idea of a normal uid getting *other* slave uids is cool but
scary at the same time.  So much infrastructure in what I think of as
"General Purpose Linux"[1] is built up around a uid - resource
restrictions and authentication for example.

I guess as long as we're sure that all cases where a "uid" crosses a
user namespace (say socket credentials) and appears as the right thing,
it may be secure.

> I think the user namespace will do what you need. Certainly it appears
> that everything in your example binary will be allowed by the time it is
> done.

That's cool, I will keep an eye on what you guys are doing.  Looks like
the containers list on linuxfoundation.org is the right one to follow?

[1] The code that's shared between RHEL and Debian roughly between the
kernel and GNOME, discarding the pointless "packaging" differences



  parent reply	other threads:[~2011-12-20 21:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07 17:54 chroot(2) and bind mounts as non-root Colin Walters
2011-12-07 19:36 ` John Stoffel
2011-12-08 16:10   ` Colin Walters
2011-12-08 18:14     ` John Stoffel
2011-12-08 18:26       ` Colin Walters
2011-12-09  0:49         ` Sven-Haegar Koch
2011-12-09 14:55         ` John Stoffel
2011-12-09 15:06           ` Colin Walters
2011-12-08 17:04   ` Arnd Bergmann
2011-12-08 17:15     ` Colin Walters
2011-12-07 19:40 ` Andy Lutomirski
2011-12-08 16:58   ` Colin Walters
2011-12-07 20:34 ` H. Peter Anvin
2011-12-07 20:54   ` Alan Cox
2011-12-15 18:55     ` Andrew G. Morgan
2011-12-16 15:44       ` Colin Walters
2011-12-18  1:22         ` Andrew G. Morgan
2011-12-18 15:19           ` Colin Walters
2011-12-10  5:29 ` Serge E. Hallyn
2011-12-12 16:41   ` Colin Walters
2011-12-12 23:11     ` Serge E. Hallyn
2011-12-15 20:56       ` Colin Walters
2011-12-16  6:14         ` Eric W. Biederman
2011-12-18 16:01           ` Colin Walters
2011-12-19  0:55             ` Eric W. Biederman
2011-12-19  4:06               ` Serge E. Hallyn
2011-12-19  9:22                 ` Eric W. Biederman
2011-12-20 16:49                   ` Colin Walters
2011-12-20 21:23               ` Colin Walters [this message]
2011-12-21 18:15           ` Steve Grubb
2012-01-03 23:13             ` 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=1324416210.25566.35.camel@lenny \
    --to=walters@verbum.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ebiederm@xmission.com \
    --cc=kzak@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=morgan@kernel.org \
    --cc=serge@hallyn.com \
    --cc=sgrubb@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.