[lxc-users] Creating a container as non root

Cal Leeming [Simplicity Media Ltd] cal.leeming at simplicitymedialtd.co.uk
Wed Aug 6 00:52:19 UTC 2014 

Also I tried to unset XDG_RUNTIME_DIR but it resulted in a new error (which
I believe is related to "sudo su" not placing into the correct cgroup)

deploy$ lxc-start -n u1
lxc_container: call to cgmanager_create_sync failed: invalid request
lxc_container: Failed to create hugetlb:u1
lxc_container: Error creating cgroup hugetlb:u1
lxc_container: failed creating cgroups
lxc_container: failed to spawn 'u1'
lxc_container: The container failed to start.
lxc_container: Additional information can be obtained by setting the
--logfile and --log-priority options.

deploy$ declare -x XDG_RUNTIME_DIR="/run/user/999"
deploy$ lxc-start -n u1
lxc-start: Permission denied - failed to create directory
'/run/user/999/lock/'
lxc-start: Error opening /tmp/1000/lxc//home/deploy/.local/share/lxc/u1
lxc-start: Failed to create lxc_container

Having to loop back using SSH feels really hacky, but I don't know enough
about LXC internals to submit a patch or suggest a cleaner workaround.

Should this be treated as a bug, or feature, or neither?

Cal



On Wed, Aug 6, 2014 at 1:45 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> Interesting, I'm running 14.04.1.
>
> 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
>
> Cal
>
>
> On Wed, Aug 6, 2014 at 1:43 AM, Serge Hallyn <serge.hallyn at ubuntu.com>
> wrote:
>
>> Quoting Cal Leeming [Simplicity Media Ltd] (
>> cal.leeming at simplicitymedialtd.co.uk):
>> > Sure;
>> >
>> > deploy$ echo $XDG_RUNTIME_DIR
>> > /run/user/999
>>
>> Right, so we're not going to have lxc second-guess your environment.
>> Note actually that on my host (ubuntu 14.10) 'sudo su otheruser' clears
>> out XDG_RUNTIME_DIR, so lxc would correctly fall back to using the new
>> $HOME.
>>
>> I'd simply recomment ssh'ing in to get a proper login environment.
>>
>> > 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
>> > >
>>
>> > _______________________________________________
>> > 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/c4b6f876/attachment-0001.html>

More information about the lxc-users mailing list