Quoting Rui Xiang (rui.xi...@huawei.com): > On 2013/7/9 23:58, Serge Hallyn wrote: > > Quoting Rui Xiang (rui.xi...@huawei.com): > >> On 2013/7/5 19:48, Serge Hallyn wrote: > >>> Quoting Rui Xiang (rui.xi...@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 ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
