<div dir="ltr">For what it's worth, I was able to get around the "sudo su" problem by doing the following;<div><br></div><div><div><div>admin$ sudo -sHu deploy</div></div></div><div>deploy$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64</div>
<div>-- snip --</div><div><div>You just created an Ubuntu container (release=trusty, arch=amd64, variant=default)</div></div><div><br></div><div>I only came across this fix from an obscure rant from someone on IRC about why "sudo su" is terrible.<br>
</div><div><br></div><div>Would seem others have had this same "sudo su" problem and it's quite unexpected, given how popular it is. </div><div><a href="https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/">https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/</a><br>
</div><div><br></div><div>It would be nice if "sudo su" was supported, as it does seem like an odd bug / "feature" :)</div><div><br></div><div>Cal</div><div><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Wed, Aug 6, 2014 at 12:06 AM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr"><<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just wanted to chime in on this, it would seem that creating unprivileged containers works fine, at least for download template of Ubuntu.<div>
<br></div><div>However the problem starts when you use "sudo su".</div>
<div><br></div><div>For example, the following breaks;</div><div><br></div><div>admin$ sudo su deploy</div><div><div>admin$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64</div><div>lxc-create: Permission denied - failed to create directory '/run/user/999/lock/'</div>
<div>lxc-create: Error opening /tmp/1000/lxc//home/deploy/.local/share/lxc/u1</div></div><div><br></div><div>But the following works;</div><div><br></div><div>admin$ ssh <a href="mailto:deploy@127.0.0.1" target="_blank">deploy@127.0.0.1</a></div>
<div><div>admin$ lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64</div><div>Setting up the GPG keyring</div><div>Downloading the image index</div></div><div><br></div><div>It would seem that lxc-create is picking up a uid 999 (admin) for the lock, and uid 1000 (deploy) for the tmp directory.</div>
<div><br></div><div>I had a quick look at the source but couldn't pin point where/why this was happening.</div><div><br></div><div>Although there are other issues with creating unprivileged containers (as per your previous discussion), this is probably a bug in its own rights.</div>
<div><br></div><div>Thoughts?</div><span class="HOEnZb"><font color="#888888"><div><br>Cal</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jan 9, 2014 at 4:11 PM, 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">Sounds good. It might be worthwhile having a 'lxc-setup-images' 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>
<span><font color="#888888"><br>
-serge<br>
</font></span><div><div><br>
Quoting Cal Leeming [Simplicity Media Ltd] (<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>):<br>
> It's also worth mentioning that fakeroot/fakechroot have some nasty 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 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 unsquashfs<br>
> to force whatever uid/gid you wanted, then fakechroot/fakeroot to make<br>
> whatever changes you need to the container before launching. The downside<br>
> is that there is no public mirror that offers this at the moment (other<br>
> than the latest 13.x ubuntu, which contains a filesystem.squashfs you can<br>
> extract, but it's 700mb). You could create your own set of base 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 tedious work<br>
> involved.<br>
><br>
> I'm planning on doing a better write up about this (as its something 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 <<a href="mailto:mhw@wittsend.com" target="_blank">mhw@wittsend.com</a>>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 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 and<br>
> > CentOS templates will not even run under a non-user (they check). His<br>
> > remark was that most templates will not and can not, including the<br>
> > Ubuntu template. Problem with the Ubuntu template (and, presumably the<br>
> > Debian template) is the use of debboot which, in turn, uses mknod 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 operations<br>
> > (chown, mknod, etc) that are simply going to require privileges in 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 optimistic.<br>
> > It does look like it checks to see if it's in a user namespace and uses<br>
> > mknod if not and does something else if it is. So, it looks like 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 a<br>
> > non-priv user if you have a recent enough kernel along with the latest<br>
> > lxc tools. But it seems likely we could ever navigate the morass 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 (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" target="_blank">(770) 978-7061</a> | mhw@WittsEnd.com<br>
> > /\/\|=mhw=|\/\/ | <a href="tel:%28678%29%20463-0932" value="+16784630932" target="_blank">(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 best of<br>
> > all<br>
> > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > lxc-users mailing list<br>
> > <a href="mailto:lxc-users@lists.linuxcontainers.org" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>