[lxc-devel] [PATCH 1/1] fix root-owned unpriv containers

[Michael H. Warfield]

On Sun, 2014-09-14 at 04:49 +0000, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at ubuntu.com):
> > On Sun, Sep 14, 2014 at 04:38:30AM +0000, Serge Hallyn wrote:
> > > lxc_map_ids was always using newuidmap if it existed.  We don't want
> > > to use it if we start as root.
> > 
> > This was actually done on purpose to force everyone with a recent
> > version of shadow to set proper ranges for root in /etc/subuid and
> > /etc/subgid to avoid potential clashes at a later point when adding new
> > users.

> Hm.  Seems to me root is not just another user who conflicts, he's a
> special user.

Hmmm...  There are two schools of thought there.  One school feels that
root is NOT a "special" user but merely one that has been permitted
special permissions.  In that universe, the root user may or may not be
unique and may or may not have universal powers.

The other school of though, obviously, is the classical one where root
(uid 0) has some very unique attributes peculiar only to the
"superuser".

It's very easy to argue that the later is merely the degenerate case of
the former where a special user is left with all capabilities.  But the
former paradigm can remove capabilities even from root and root is not
unique or special then.  A "rootless" distribution has been
demonstrated.

I may be mistaken, but I thought one of the goals of the entire
"capabilities" effort in the kernel years ago was to support the former
philosophy over the later.  In that case, root is special only that root
remains with all the caps enabled.  I thought (but I haven't had my nose
stuck in kernel code in way too long) that all the "isroot" (or some
such) checks were suppose to be converted "has_capability" (or some
such).  My kernel device driver didn't need any of that so I didn't
follow it in great detail.

I may be (very very) old school but the old school UNIX has a preference
for "no magic cookies" and root (uid 0) was always a glaring exception.
Intellectually, I like the idea that:

1) UID 0 is not a magic cookie...

2) UID 0 can be stripped of capabilities...

3) UID != 0 can have root like capabilities...

By the time you make the transition state from runlevel (to use to the
classical terminology) 0 (S) to any higher runlevel, you've established
those capabilities before the system has become multiuser.

> In any case if we're going to stick with that then it needs to be
> better documented :)

> On a related note, I'm thinking that the chmod'ing of container dirs
> in unpriv users' .local/share/lxc was the wrong approach.  Perhaps we should
> instead chmod .local/share/lxc itself to be 700.  Have the user create
> and chdir to .local/share/lxc/containerdir under his own euid, make
> that 755, and work under there.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140914/871db1f4/attachment.sig>