[lxc-devel] Howto user namespaces?

Rui Xiang rui.xiang at huawei.com
Fri Jul 12 02:06:39 UTC 2013


On 2013/7/11 22:26, Serge Hallyn wrote:
> 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?
> 

Yes, sure. Before I started the container, the files status liked:
 # ll
  drwxr-xr-x  2 xiangrui nstest  4096 Jul 11 19:47 bin
  drwxr-xr-x  2 xiangrui nstest  4096 Jul 11 19:47 boot
  ...
  drwxr-xr-x  2 xiangrui nstest  4096 Jul 11 19:47 proc
  drwxr-xr-x  2 xiangrui nstest  4096 Jul 11 19:47 sys

>> and I can set some proc files that are not isolated with host.
> 
> Could you be more precise?  What do you mean by this?
> 

In my view, user in container have no permission to access and set proc file 
like /proc/sys/vm/dirty_ratio because the proc files are not isolated 
with host, right?

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

Means that the container I created is still problematic obviously, but
 not shows lxc sources certainly have any problems. :) I can't confirm 
what cause this container unavailability yet, 


Thanks.







More information about the lxc-devel mailing list