<div dir="ltr">Interesting, I'm running 14.04.1.<div><br></div><div>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</div>
<div><br></div><div>Cal</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 1:43 AM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Quoting Cal Leeming [Simplicity Media Ltd] (<a href="mailto:cal.leeming@simplicitymedialtd.co.uk">cal.leeming@simplicitymedialtd.co.uk</a>):<br>
</div><div class="">> Sure;<br>
><br>
> deploy$ echo $XDG_RUNTIME_DIR<br>
> /run/user/999<br>
<br>
</div>Right, so we're not going to have lxc second-guess your environment.<br>
Note actually that on my host (ubuntu 14.10) 'sudo su otheruser' clears<br>
out XDG_RUNTIME_DIR, so lxc would correctly fall back to using the new<br>
$HOME.<br>
<br>
I'd simply recomment ssh'ing in to get a proper login environment.<br>
<div class="HOEnZb"><div class="h5"><br>
> deploy$ echo $HOME<br>
> /home/deploy<br>
><br>
> deploy$ cat /proc/self/cgroup<br>
> 11:hugetlb:/<br>
> 10:perf_event:/<br>
> 9:blkio:/<br>
> 8:freezer:/<br>
> 7:devices:/<br>
> 6:memory:/<br>
> 5:cpuacct:/<br>
> 4:cpu:/<br>
> 3:cpuset:/<br>
> 2:name=systemd:/user/999.user/5.session<br>
><br>
> Expected uid is 1000 (deploy) but its showing 999 (admin).<br>
><br>
><br>
> Cal<br>
><br>
><br>
> On Wed, Aug 6, 2014 at 12:22 AM, Serge Hallyn <<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a>><br>
> wrote:<br>
><br>
> > Quoting Cal Leeming [Simplicity Media Ltd] (<br>
> > <a href="mailto:cal.leeming@simplicitymedialtd.co.uk">cal.leeming@simplicitymedialtd.co.uk</a>):<br>
> > > Just wanted to chime in on this, it would seem that creating unprivileged<br>
> > > containers works fine, at least for download template of Ubuntu.<br>
> > ><br>
> > > However the problem starts when you use "sudo su".<br>
> > ><br>
> > > For example, the following breaks;<br>
> > ><br>
> > > admin$ sudo su deploy<br>
> > > admin$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64<br>
> > > lxc-create: Permission denied - failed to create directory<br>
> > > '/run/user/999/lock/'<br>
> ><br>
> > From this shell, what do 'echo $XDG_RUNTIME_DIR' and 'echo $HOME' say?<br>
> ><br>
> > > lxc-create: Error opening /tmp/1000/lxc//home/deploy/.local/share/lxc/u1<br>
> > ><br>
> > > But the following works;<br>
> > ><br>
> > > admin$ ssh <a href="mailto:deploy@127.0.0.1">deploy@127.0.0.1</a><br>
> > > admin$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64<br>
> > > Setting up the GPG keyring<br>
> > > Downloading the image index<br>
> > ><br>
> > > It would seem that lxc-create is picking up a uid 999 (admin) for the<br>
> > lock,<br>
> > > and uid 1000 (deploy) for the tmp directory.<br>
> > ><br>
> > > I had a quick look at the source but couldn't pin point where/why this<br>
> > was<br>
> > > happening.<br>
> > ><br>
> > > Although there are other issues with creating unprivileged containers (as<br>
> > > per your previous discussion), this is probably a bug in its own rights.<br>
> > ><br>
> > > Thoughts?<br>
> > ><br>
> > > Cal<br>
> > ><br>
> > ><br>
> > ><br>
> > > On Thu, Jan 9, 2014 at 4:11 PM, Serge Hallyn <<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > > Sounds good. It might be worthwhile having a 'lxc-setup-images'<br>
> > command<br>
> > > > which requires root and builds the base images. Then unprileged users<br>
> > > > could untar/unsquash those images.<br>
> > > ><br>
> > > > To be clear, I absolutely *can* create and run ubuntu-cloud images<br>
> > > > without being root.<br>
> > > ><br>
> > > > -serge<br>
> > > ><br>
> > > > Quoting Cal Leeming [Simplicity Media Ltd] (<br>
> > > > <a href="mailto:cal.leeming@simplicitymedialtd.co.uk">cal.leeming@simplicitymedialtd.co.uk</a>):<br>
> > > > > It's also worth mentioning that fakeroot/fakechroot have some nasty<br>
> > > > issues<br>
> > > > > with debootstrap;<br>
> > > > > <a href="https://bugs.launchpad.net/ubuntu/+source/fakechroot/+bug/1265857" target="_blank">https://bugs.launchpad.net/ubuntu/+source/fakechroot/+bug/1265857</a><br>
> > > > ><br>
> > > > > One theory I'm exploring is building "base images" on a machine that<br>
> > does<br>
> > > > > have root, by running debootstrap on every flavor/arch then using<br>
> > > > > mksquashfs to compress it down into an image. You could then use<br>
> > > > unsquashfs<br>
> > > > > to force whatever uid/gid you wanted, then fakechroot/fakeroot to<br>
> > make<br>
> > > > > whatever changes you need to the container before launching. The<br>
> > downside<br>
> > > > > is that there is no public mirror that offers this at the moment<br>
> > (other<br>
> > > > > than the latest 13.x ubuntu, which contains a filesystem.squashfs<br>
> > you can<br>
> > > > > extract, but it's 700mb). You could create your own set of base<br>
> > images,<br>
> > > > > then wrap scripts around them to create the templates, but this is<br>
> > > > > absolutely not going to work out of the box, there is a lot of<br>
> > tedious<br>
> > > > work<br>
> > > > > involved.<br>
> > > > ><br>
> > > > > I'm planning on doing a better write up about this (as its something<br>
> > I'm<br>
> > > > > actively working on), will update this thread at a later date.<br>
> > > > ><br>
> > > > > Hope this helps a bit<br>
> > > > ><br>
> > > > > Cal<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > On Thu, Jan 9, 2014 at 3:39 PM, Michael H. Warfield <<br>
> > <a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a><br>
> > > > >wrote:<br>
> > > > ><br>
> > > > > > On Thu, 2014-01-09 at 08:08 +0200, Kevin Wilson wrote:<br>
> > > > > > > Hello,<br>
> > > > > > > I believe that creating a container as non root user should be<br>
> > > > > > straight-forward.<br>
> > > > > ><br>
> > > > > > Sigh... I'm afraid not...<br>
> > > > > ><br>
> > > > > > Funny, Serge and I just had a couple of comments in exchange about<br>
> > this<br>
> > > > > > very thing with regards to templates. He's been working on getting<br>
> > > > > > containers to run under unprivileged users and I know the Fedora<br>
> > and<br>
> > > > > > CentOS templates will not even run under a non-user (they check).<br>
> > His<br>
> > > > > > remark was that most templates will not and can not, including the<br>
> > > > > > Ubuntu template. Problem with the Ubuntu template (and,<br>
> > presumably the<br>
> > > > > > Debian template) is the use of debboot which, in turn, uses mknod<br>
> > to<br>
> > > > > > create devices for the container - and you're then toast.<br>
> > > > > ><br>
> > > > > > The problem there is that there are going to be privileged<br>
> > operations<br>
> > > > > > (chown, mknod, etc) that are simply going to require privileges in<br>
> > the<br>
> > > > > > host which are not available to the non-priv user.<br>
> > > > > ><br>
> > > > > > I'm not so sure about the busybox template but I wouldn't be<br>
> > > > optimistic.<br>
> > > > > > It does look like it checks to see if it's in a user namespace and<br>
> > uses<br>
> > > > > > mknod if not and does something else if it is. So, it looks like<br>
> > it<br>
> > > > > > SHOULD work. But you have to have user namespaces set up to work.<br>
> > > > > ><br>
> > > > > > Once a container is created, it should be possible to run it under<br>
> > a<br>
> > > > > > non-priv user if you have a recent enough kernel along with the<br>
> > latest<br>
> > > > > > lxc tools. But it seems likely we could ever navigate the morass<br>
> > of<br>
> > > > > > creating a template using lxc-create as a non-priv user.<br>
> > > > > ><br>
> > > > > > > I added a user named "test" and I am trying to create a container<br>
> > > > (see<br>
> > > > > > > below the sequence). I am running latest lxc git<br>
> > > > > > > (built from source, as root) on Fedora 20.<br>
> > > > > ><br>
> > > > > > > useradd test<br>
> > > > > > > su test<br>
> > > > > > ><br>
> > > > > > > lxc-create -t busybox -n busyboxTest<br>
> > > > > > > I get:<br>
> > > > > > ><br>
> > > > > > > You lack access to /home/test/.local/share/lxc/<br>
> > > > > > > I ran;<br>
> > > > > > > mkdir -p /home/test/.local/share/lxc/<br>
> > > > > > ><br>
> > > > > > > Then again:<br>
> > > > > > > lxc-create -t busybox -n busyboxTest<br>
> > > > > > > lxc-create: Permission denied - failed to create directory<br>
> > > > > > '/run/user/0/lock/'<br>
> > > > > > ><br>
> > > > > > > failed to create lock<br>
> > > > > > > System error loading container<br>
> > > > > > ><br>
> > > > > > > What should I do ?<br>
> > > > > > ><br>
> > > > > > > Regards,<br>
> > > > > > > Kevin<br>
> > > > > ><br>
> > > > > > Regards,<br>
> > > > > > Mike<br>
> > > > > > --<br>
> > > > > > Michael H. Warfield (AI4NB) | <a href="tel:%28770%29%20978-7061" value="+17709787061">(770) 978-7061</a> | mhw@WittsEnd.com<br>
> > > > > > /\/\|=mhw=|\/\/ | <a href="tel:%28678%29%20463-0932" value="+16784630932">(678) 463-0932</a> |<br>
> > > > > > <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
> > > > > > NIC whois: MHW9 | An optimist believes we live in the<br>
> > best<br>
> > > > of<br>
> > > > > > all<br>
> > > > > > PGP Key: 0x674627FF | possible worlds. A pessimist is<br>
> > sure of<br>
> > > > it!<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > _______________________________________________<br>
> > > > > > lxc-users mailing list<br>
> > > > > > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > > > > > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
> > > > > ><br>
> > > ><br>
> > > > > _______________________________________________<br>
> > > > > lxc-users mailing list<br>
> > > > > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > > > > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > lxc-users mailing list<br>
> > > > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > > > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > lxc-users mailing list<br>
> > > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
> ><br>
> > _______________________________________________<br>
> > lxc-users mailing list<br>
> > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
> ><br>
<br>
> _______________________________________________<br>
> lxc-users mailing list<br>
> <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
<br>
_______________________________________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a></div></div></blockquote></div><br></div>