Also found this discussion on the matter in systemd; http://lists.freedesktop.org/archives/systemd-devel/2013-November/014370.html
Cal On Wed, Aug 6, 2014 at 1:26 AM, Cal Leeming [Simplicity Media Ltd] < [email protected]> wrote: > (sorry hit return too fast). > > Also turns out that the sudo -shU trick doesn't work, results in; > > deploy$ lxc-start -n u1 > lxc_container: call to cgmanager_create_sync failed: invalid request > > Found another semi related ticket; > https://github.com/lxc/lxc/issues/181 > > Cal > > > > On Wed, Aug 6, 2014 at 1:24 AM, Cal Leeming [Simplicity Media Ltd] < > [email protected]> wrote: > >> Sure; >> >> deploy$ echo $XDG_RUNTIME_DIR >> /run/user/999 >> 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
