[lxc-users] Creating a container as non root

Wed Aug 6 00:32:57 UTC 2014

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] <
cal.leeming at simplicitymedialtd.co.uk> 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] <
> cal.leeming at simplicitymedialtd.co.uk> 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 <serge.hallyn at ubuntu.com>
>> wrote:
>>
>>> Quoting Cal Leeming [Simplicity Media Ltd] (
>>> cal.leeming at simplicitymedialtd.co.uk):
>>> > 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 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
>>> > >
>>>
>>> > _______________________________________________
>>> > 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/32e3bfdc/attachment-0001.html>