[lxc-users] Creating a container as non root

Tue Aug 5 23:06:37 UTC 2014

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/'
lxc-create: Error opening /tmp/1000/lxc//home/deploy/.local/share/lxc/u1

But the following works;

admin$ ssh deploy at 127.0.0.1
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 <serge.hallyn at ubuntu.com>
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] (
> cal.leeming at simplicitymedialtd.co.uk):
> > 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 <mhw at wittsend.com
> >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 |  mhw at WittsEnd.com
> > >    /\/\|=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
> > > lxc-users at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> > >
>
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140806/d94f0b81/attachment-0001.html>