Also I tried to unset XDG_RUNTIME_DIR but it resulted in a new error (which I believe is related to "sudo su" not placing into the correct cgroup)
deploy$ lxc-start -n u1 lxc_container: call to cgmanager_create_sync failed: invalid request lxc_container: Failed to create hugetlb:u1 lxc_container: Error creating cgroup hugetlb:u1 lxc_container: failed creating cgroups lxc_container: failed to spawn 'u1' lxc_container: The container failed to start. lxc_container: Additional information can be obtained by setting the --logfile and --log-priority options. deploy$ declare -x XDG_RUNTIME_DIR="/run/user/999" deploy$ lxc-start -n u1 lxc-start: Permission denied - failed to create directory '/run/user/999/lock/' lxc-start: Error opening /tmp/1000/lxc//home/deploy/.local/share/lxc/u1 lxc-start: Failed to create lxc_container Having to loop back using SSH feels really hacky, but I don't know enough about LXC internals to submit a patch or suggest a cleaner workaround. Should this be treated as a bug, or feature, or neither? Cal On Wed, Aug 6, 2014 at 1:45 AM, Cal Leeming [Simplicity Media Ltd] < [email protected]> wrote: > Interesting, I'm running 14.04.1. > > Could you paste your output of /proc/self/cgroup from inside your "sudo > su" ? I'd be interested to see if the systemd entry is correct too > > Cal > > > On Wed, Aug 6, 2014 at 1:43 AM, Serge Hallyn <[email protected]> > wrote: > >> Quoting Cal Leeming [Simplicity Media Ltd] ( >> [email protected]): >> > Sure; >> > >> > deploy$ echo $XDG_RUNTIME_DIR >> > /run/user/999 >> >> Right, so we're not going to have lxc second-guess your environment. >> Note actually that on my host (ubuntu 14.10) 'sudo su otheruser' clears >> out XDG_RUNTIME_DIR, so lxc would correctly fall back to using the new >> $HOME. >> >> I'd simply recomment ssh'ing in to get a proper login environment. >> >> > deploy$ echo $HOME >> > /home/deploy >> > >> > deploy$ cat /proc/self/cgroup >> > 11:hugetlb:/ >> > 10:perf_event:/ >> > 9:blkio:/ >> > 8:freezer:/ >> > 7:devices:/ >> > 6:memory:/ >> > 5:cpuacct:/ >> > 4:cpu:/ >> > 3:cpuset:/ >> > 2:name=systemd:/user/999.user/5.session >> > >> > Expected uid is 1000 (deploy) but its showing 999 (admin). >> > >> > >> > Cal >> > >> > >> > On Wed, Aug 6, 2014 at 12:22 AM, Serge Hallyn <[email protected]> >> > wrote: >> > >> > > Quoting Cal Leeming [Simplicity Media Ltd] ( >> > > [email protected]): >> > > > Just wanted to chime in on this, it would seem that creating >> unprivileged >> > > > containers works fine, at least for download template of Ubuntu. >> > > > >> > > > However the problem starts when you use "sudo su". >> > > > >> > > > For example, the following breaks; >> > > > >> > > > admin$ sudo su deploy >> > > > admin$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64 >> > > > lxc-create: Permission denied - failed to create directory >> > > > '/run/user/999/lock/' >> > > >> > > From this shell, what do 'echo $XDG_RUNTIME_DIR' and 'echo $HOME' say? >> > > >> > > > lxc-create: Error opening >> /tmp/1000/lxc//home/deploy/.local/share/lxc/u1 >> > > > >> > > > But the following works; >> > > > >> > > > admin$ ssh [email protected] >> > > > admin$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64 >> > > > Setting up the GPG keyring >> > > > Downloading the image index >> > > > >> > > > It would seem that lxc-create is picking up a uid 999 (admin) for >> the >> > > lock, >> > > > and uid 1000 (deploy) for the tmp directory. >> > > > >> > > > I had a quick look at the source but couldn't pin point where/why >> this >> > > was >> > > > happening. >> > > > >> > > > Although there are other issues with creating unprivileged >> containers (as >> > > > per your previous discussion), this is probably a bug in its own >> rights. >> > > > >> > > > Thoughts? >> > > > >> > > > Cal >> > > > >> > > > >> > > > >> > > > On Thu, Jan 9, 2014 at 4:11 PM, Serge Hallyn < >> [email protected]> >> > > > wrote: >> > > > >> > > > > Sounds good. It might be worthwhile having a 'lxc-setup-images' >> > > command >> > > > > which requires root and builds the base images. Then unprileged >> users >> > > > > could untar/unsquash those images. >> > > > > >> > > > > To be clear, I absolutely *can* create and run ubuntu-cloud images >> > > > > without being root. >> > > > > >> > > > > -serge >> > > > > >> > > > > Quoting Cal Leeming [Simplicity Media Ltd] ( >> > > > > [email protected]): >> > > > > > It's also worth mentioning that fakeroot/fakechroot have some >> nasty >> > > > > issues >> > > > > > with debootstrap; >> > > > > > >> https://bugs.launchpad.net/ubuntu/+source/fakechroot/+bug/1265857 >> > > > > > >> > > > > > One theory I'm exploring is building "base images" on a machine >> that >> > > does >> > > > > > have root, by running debootstrap on every flavor/arch then >> using >> > > > > > mksquashfs to compress it down into an image. You could then use >> > > > > unsquashfs >> > > > > > to force whatever uid/gid you wanted, then fakechroot/fakeroot >> to >> > > make >> > > > > > whatever changes you need to the container before launching. The >> > > downside >> > > > > > is that there is no public mirror that offers this at the moment >> > > (other >> > > > > > than the latest 13.x ubuntu, which contains a >> filesystem.squashfs >> > > you can >> > > > > > extract, but it's 700mb). You could create your own set of base >> > > images, >> > > > > > then wrap scripts around them to create the templates, but this >> is >> > > > > > absolutely not going to work out of the box, there is a lot of >> > > tedious >> > > > > work >> > > > > > involved. >> > > > > > >> > > > > > I'm planning on doing a better write up about this (as its >> something >> > > I'm >> > > > > > actively working on), will update this thread at a later date. >> > > > > > >> > > > > > Hope this helps a bit >> > > > > > >> > > > > > Cal >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Thu, Jan 9, 2014 at 3:39 PM, Michael H. Warfield < >> > > [email protected] >> > > > > >wrote: >> > > > > > >> > > > > > > On Thu, 2014-01-09 at 08:08 +0200, Kevin Wilson wrote: >> > > > > > > > Hello, >> > > > > > > > I believe that creating a container as non root user should >> be >> > > > > > > straight-forward. >> > > > > > > >> > > > > > > Sigh... I'm afraid not... >> > > > > > > >> > > > > > > Funny, Serge and I just had a couple of comments in exchange >> about >> > > this >> > > > > > > very thing with regards to templates. He's been working on >> getting >> > > > > > > containers to run under unprivileged users and I know the >> Fedora >> > > and >> > > > > > > CentOS templates will not even run under a non-user (they >> check). >> > > His >> > > > > > > remark was that most templates will not and can not, >> including the >> > > > > > > Ubuntu template. Problem with the Ubuntu template (and, >> > > presumably the >> > > > > > > Debian template) is the use of debboot which, in turn, uses >> mknod >> > > to >> > > > > > > create devices for the container - and you're then toast. >> > > > > > > >> > > > > > > The problem there is that there are going to be privileged >> > > operations >> > > > > > > (chown, mknod, etc) that are simply going to require >> privileges in >> > > the >> > > > > > > host which are not available to the non-priv user. >> > > > > > > >> > > > > > > I'm not so sure about the busybox template but I wouldn't be >> > > > > optimistic. >> > > > > > > It does look like it checks to see if it's in a user >> namespace and >> > > uses >> > > > > > > mknod if not and does something else if it is. So, it looks >> like >> > > it >> > > > > > > SHOULD work. But you have to have user namespaces set up to >> work. >> > > > > > > >> > > > > > > Once a container is created, it should be possible to run it >> under >> > > a >> > > > > > > non-priv user if you have a recent enough kernel along with >> the >> > > latest >> > > > > > > lxc tools. But it seems likely we could ever navigate the >> morass >> > > of >> > > > > > > creating a template using lxc-create as a non-priv user. >> > > > > > > >> > > > > > > > I added a user named "test" and I am trying to create a >> container >> > > > > (see >> > > > > > > > below the sequence). I am running latest lxc git >> > > > > > > > (built from source, as root) on Fedora 20. >> > > > > > > >> > > > > > > > useradd test >> > > > > > > > su test >> > > > > > > > >> > > > > > > > lxc-create -t busybox -n busyboxTest >> > > > > > > > I get: >> > > > > > > > >> > > > > > > > You lack access to /home/test/.local/share/lxc/ >> > > > > > > > I ran; >> > > > > > > > mkdir -p /home/test/.local/share/lxc/ >> > > > > > > > >> > > > > > > > Then again: >> > > > > > > > lxc-create -t busybox -n busyboxTest >> > > > > > > > lxc-create: Permission denied - failed to create directory >> > > > > > > '/run/user/0/lock/' >> > > > > > > > >> > > > > > > > failed to create lock >> > > > > > > > System error loading container >> > > > > > > > >> > > > > > > > What should I do ? >> > > > > > > > >> > > > > > > > Regards, >> > > > > > > > Kevin >> > > > > > > >> > > > > > > Regards, >> > > > > > > Mike >> > > > > > > -- >> > > > > > > Michael H. Warfield (AI4NB) | (770) 978-7061 | >> [email protected] >> > > > > > > /\/\|=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! >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > lxc-users mailing list >> > > > > > > [email protected] >> > > > > > > http://lists.linuxcontainers.org/listinfo/lxc-users >> > > > > > > >> > > > > >> > > > > > _______________________________________________ >> > > > > > lxc-users mailing list >> > > > > > [email protected] >> > > > > > http://lists.linuxcontainers.org/listinfo/lxc-users >> > > > > >> > > > > _______________________________________________ >> > > > > lxc-users mailing list >> > > > > [email protected] >> > > > > http://lists.linuxcontainers.org/listinfo/lxc-users >> > > > > >> > > >> > > > _______________________________________________ >> > > > lxc-users mailing list >> > > > [email protected] >> > > > http://lists.linuxcontainers.org/listinfo/lxc-users >> > > >> > > _______________________________________________ >> > > lxc-users mailing list >> > > [email protected] >> > > http://lists.linuxcontainers.org/listinfo/lxc-users >> > > >> >> > _______________________________________________ >> > lxc-users mailing list >> > [email protected] >> > http://lists.linuxcontainers.org/listinfo/lxc-users >> >> _______________________________________________ >> lxc-users mailing list >> [email protected] >> http://lists.linuxcontainers.org/listinfo/lxc-users >> > >
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
