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 <[email protected]> wrote: > Quoting Cal Leeming [Simplicity Media Ltd] ( > [email protected]): > > 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 <[email protected]> > > wrote: > > > > > Quoting Cal Leeming [Simplicity Media Ltd] ( > > > [email protected]): > > > > 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 [email protected] > > > > 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 < > [email protected]> > > > > 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] ( > > > > > [email protected]): > > > > > > 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 < > > > [email protected] > > > > > >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 | > [email protected] > > > > > > > /\/\|=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 > > > > > > > [email protected] > > > > > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > lxc-users mailing list > > > > > > [email protected] > > > > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > > > > > _______________________________________________ > > > > > lxc-users mailing list > > > > > [email protected] > > > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > > > > > > > _______________________________________________ > > > > lxc-users mailing list > > > > [email protected] > > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > _______________________________________________ > > > lxc-users mailing list > > > [email protected] > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > _______________________________________________ > > lxc-users mailing list > > [email protected] > > http://lists.linuxcontainers.org/listinfo/lxc-users > > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users >
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
