[lxc-devel] Howto user namespaces?

[Serge Hallyn]

Quoting Rui Xiang (rui.xiang at huawei.com):
> On 2013/7/9 23:58, Serge Hallyn wrote:
> > Quoting Rui Xiang (rui.xiang at huawei.com):
> >> On 2013/7/5 19:48, Serge Hallyn wrote:
> >>> Quoting Rui Xiang (rui.xiang at huawei.com):
> >>>> The same issue troubles me. I try to start the container by these ways 
> 
> ...
> 
> >>  
> >> After setting lxc.tty = 0, the result was error too:
> >>   lxc-start: Operation not permitted - failed to set mode '020644' to '/dev/pts/1'.
> >>
> >> So ashamed that I have no better ways to solve it now. :(
> > 
> > Hi,
> > 
> > When you do
> > 
> >   lxc.id_map = u 0 10000 2000
> >   lxc.id_map = g 0 10000 2000
> > 
> > The container will run with uid 0 in the container being mapped to 10000
> > on the host.  What I don't see is where you have shifted the uids of the
> > container's files.
> 
> Ah.., forgot to say that I used chown to the rootfs of this container:
>  # chown 10000 ./rootfs
> 
> > If you look at https://code.launchpad.net/~serge-hallyn/+junk/nsexec ,
> > there are two programs of interest.  uidmapshift.c will do the uid
> > shifting (so for instance root owned files in the container will become
> > owned by 10000).  The container-userns-convert script will use the
> > uidmapshift.c program as well as add the lxc.id_map files to the
> > container configuration.  I usually just do
> > 
> > 	container-userns-convert containername 10000
> > 
> > So you'll definately need to use the uidmapshift program to chown your
> > files, though to be honest your error sounds to me like a different
> > problem.  But just to be sure, please let me know what you see after
> > shifting the container uids.
> 
> After using container-userns-convert script and uidmapshift program to chown 
> rootfs, I can run container successfully. But in the container, I found the 
> files attribute like :
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 bin
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 boot
> drwxr-xr-x   8 10000 10000  4096 Jul 11 12:28 dev
> drwxr-xr-x  67 10000 10000  4096 Jul 11 12:28 etc
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 home
> drwxr-xr-x   9 10000 10000  4096 Jul 11 11:47 lib
> drwxr-xr-x   7 10000 10000  4096 Jul 11 11:47 lib64
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 media
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 mnt
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 opt
> dr-xr-xr-x 255 root  root      0 Jul 11 12:28 proc
> drwxr-xr-x   4 10000 10000  4096 Jul 11 11:47 root
> drwxr-xr-x   3 10000 10000 12288 Jul 11 11:47 sbin
> drwxr-xr-x   2 10000 10000  4096 Jul 11 11:47 selinux
> drwxr-xr-x   4 10000 10000  4096 Jul 11 11:47 srv
> dr-xr-xr-x  12 root  root      0 Jul 11 12:28 sys
> drwxr-xr-t   4 10000 10000  4096 Jul 11 12:28 tmp
> drwxr-xr-x  13 10000 10000  4096 Jul 11 11:47 usr
> drwxr-xr-x  14 10000 10000  4096 Jul 11 11:47 var

Could you make sure that proc and sys exist and get chowned before
you ever try to start the container?

> and I can set some proc files that are not isolated with host.

Could you be more precise?  What do you mean by this?

> IMO, the container is still problematic obvious, right ?

Not sure what 'problematic obvious' means.  But so far AFAIK only
Dwight and I ever test these, so I do expect problems.

-serge