On Mon, 27 Oct 2014 04:31:05 -0500 Corey Wright <undefined@pobox.com> wrote: > the attached patch (in conjuction with [1] for linux 3.14.22, though possibly > still applicable to kernels < 3.14.19 without those additional patches) > allows linux 3.14 to compile and run with CONFIG_USER_NS, including > containers. > > [1] http://archives.linux-vserver.org/201410/0050.html > > WARNING: > 1. this is not production quality and only made available for testing. > 2. i don't know the security ramifications of running both vservers and > containers on a single host. > 3. it is conceivable that containers can run inside of vservers with the > provided patch, but i haven't tested such nor do i know the security > ramifications. > > NOTES: > 1. vservers will not use user namespaces by default. [2] > 2. vservers cannot use user namespaces without changes to util-vserver and > possibly more kernel changes. [3] > 3. lxc should work. [4] > > [2] in the attached patch CLONE_NEWUSER is commented out in > default_space_mask which prevents util-vserver from using user namespaces with > vservers. > > [3] vspace needs to create uid and gid mappings for the new user namespace > between sys_clone() and execvp() calls otherwise all capabilities, > specifically CAP_CONTEXT, are removed from the executed vcontext because the > uid and gid are 65535. see https://lwn.net/Articles/532593/, specifically > the section "Capabilities, execve(), and user ID 0". > > [4] tested with lxc 1.0.6 on linux 3.14.22-vs2.3.6.13 with the attached > userns patch by creating a container ("SUITE=wheezy > MIRROR=http://http.us.debian.org/debian lxc-create -n test -t debian"), > starting the container ("lxc-start -n test -d"), and attaching to the console > ("lxc-console -n test"), and stopping the container ("lxc-stop -n test") > though i was unable to log into the container ("unable to determine your tty > name"), but i believe that to be a configuration problem with the > installation inside the container. the problem with logging into the container is because /proc/self is not accessible in a container: root@debian-wheezy-vserver:~# lxc-attach -n debian-wheezy-amd64 root@debian-wheezy-amd64:~# ls -l /proc/self ls: cannot read symbolic link /proc/self: No such file or directory lrwxrwxrwx 1 root root 0 Nov 1 23:14 /proc/self this problem has been isolated to the linux-vserver patch as the problem is not seen on a non-patched kernel and happens regardless of my linux-vserver user namespace patch. i tried finding the problem but debugging with "echo 255 >/proc/sys/vserver/debug_*" (not literally, but you get the point) didn't show anything relevant in the kernel logs and the linux-vserver patch only adds a line of commented-out code to fs/proc/self.c. corey -- undefined@pobox.com > FULL DISCLOSURE: > 1. the last two hunks are not both necessary. commenting out CLONE_NEWUSER > in default_space_mask is used to keep util-vserver from using user namespaces > for vservers. changing "capable()" to "ns_capable()" is required to use > linux-vserver system calls within a user namespace (and is there currently > for testing as it's not that useful without the aforementioned changes to > util-vserver). you really only need one or the other and the last hunk is > not that useful without changes to util-vserver (and more changes might be > necessary). > > please test and provide feedback, especially if you have better suggestions to > simply test lxc/containers as i'm a newbie in that area. > > corey > -- > undefined@pobox.com