lxc-ls requires root access after deploying an LXC instance

Bug #930430 reported by Jamie Strandboge
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
pyjuju
Fix Released
High
Clint Byrum
juju (Ubuntu)
Confirmed
High
Unassigned
lxc (Ubuntu)
Invalid
High
Unassigned

Bug Description

On up to date precise:

1. $ sudo apt-get install juju charm-tools apt-cacher-ng zookeeper libvirt-bin lxc

2. $ adduser <yourusername> libvirtd

3. logout and back in

4. $ mkdir .juju

5. create the juju environments configuration
$ cat > .juju/environments.yaml <<EOF
environments:
  local:
    type: local
    data-dir: /tmp/juju-local
    admin-secret: abcdefghijklmnopqrstuvwxyz1234567890
    control-bucket: foo-bucket
    default-series: oneiric
EOF

6. ssh-keygen -t rsa -b 2048 # only if needed

7. $ juju bootstrap

8. $ lxc-ls # ok
<yourusername>-local-0-template

9. $ juju deploy --repository=/usr/share/doc/juju/examples local:oneiric/wordpress

10. $ sleep 60 ; lxc-ls
<yourusername>-local-0-template <yourusername>-local-wordpress-1
/usr/bin/lxc-ls: line 35: cd: /sys/fs/cgroup/cpuset///lxc: Permission denied
ls: cannot access <yourusername>-local-wordpress-1: No such file or directory

$ ls -ld /sys/fs/cgroup/cpuset///lxc
drwx------ 3 root root 0 Feb 10 15:39 /sys/fs/cgroup/cpuset///lxc

But /sys/fs/cgroup/cpuset///lxc was 700 before I deploy the juju instance.

Related branches

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Thanks, Jamie, I will try to reproduce with your recipe.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

@Jamie,

to help me gauge priority - is this in any way blocking you? If not I'll
mark it as low priority since sudo is a workaround :)

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This is not blocking me.

Changed in juju (Ubuntu):
status: New → Confirmed
Changed in lxc (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Changed in juju (Ubuntu):
importance: Undecided → High
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

If I first
   lxc-create -t ubuntu -n oneiric
   lxc-start -n oneiric
   (and then shut that down)

and then do juju bootstrap and deploy, it goes fine. It seems like juju is chmod'ing the lxc cgroup directories, but I don't see where (or why).

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

This is odd, I seem to have lost a bunch of comments - meaning I must have added them to the wrong bug!

The gist is, this is not a bug in lxc in my opinion. Lxc creates the /sys/fs/cgroup/xyz/lxc directories using mkdir(2) passing 0755 as the mode. That mode is masked with the task's umask. juju is running lxc-start with a umask of 0077, rather than the usual 0022. That is the reason the directory gets the wrong permissions.

Lxc could go in and chmod the directories by hand, but that would be wrong. The umask presumably is set as it is for a reason.

In my opinion, juju should change its umask to 0022 before calling lxc-create.

Changed in lxc (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Hi Jamie,

I started seeing this with juju 0.5.1+bzr563-0juju2~precise1, to which I recently upgraded. With 0.5+bzr531-0ubuntu1.2 (also in precise) it works.

Revision history for this message
ZhengPeng Hou (zhengpeng-hou) wrote :

I encountered with this issue when I was trying to destroy a local environment. I have no problem to bootstrap/deploy service locally.

Changed in juju:
status: New → Triaged
importance: Undecided → High
milestone: none → 0.6
Revision history for this message
Kapil Thangavelu (hazmat) wrote : Re: [Bug 930430] Re: lxc-ls requires root access after deploying an LXC instance

I've just noticed this with some of the unit tests, afaik this is some
change in lxc behavior.

$ lxc-ls
kapil-dev-0-template kapil-dev-wordpress-0 monitoring
/usr/bin/lxc-ls: line 35: cd: /sys/fs/cgroup/cpuset///lxc: Permission denied
ls: cannot access kapil-dev-wordpress-0: No such file or directory

it only happens for trying to access the running containers.

-k

On Thu, Sep 20, 2012 at 1:31 AM, Clint Byrum <email address hidden> wrote:

> ** Also affects: juju
> Importance: Undecided
> Status: New
>
> ** Changed in: juju
> Status: New => Triaged
>
> ** Changed in: juju
> Importance: Undecided => High
>
> ** Changed in: juju
> Milestone: None => 0.6
>
> --
> You received this bug notification because you are subscribed to juju.
> https://bugs.launchpad.net/bugs/930430
>
> Title:
> lxc-ls requires root access after deploying an LXC instance
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/930430/+subscriptions
>

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Quoting Kapil Thangavelu (<email address hidden>):
> I've just noticed this with some of the unit tests, afaik this is some
> change in lxc behavior.

I don't think it's a change in lxc behavior. I think it's a change in
the umask which juju has set when it calls lxc-start.

lxc passes a requested mode to mkdir(2), which then &s that with the
umask.

Ideally juju would set umask correctly. There are two ways lxc could
help, but they're not particularly palatable.

It could second-guess the caller and hand-set umask before calling
mkdir. I think that's Wrong.

It could check umask and spit out an error if it is too restrictive.
That will help users find the cause more quickly, but doesn't solve
the bug.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

It would appear that the problem happens because of twistd's default behavior when daemonizing. It always sets umask to 0077. On non-local images, we don't daemonize because the agents are run via upstart in --nodaemonize mode.

I have a fix for this in the local-cloud-img branch, which is to explicitly set the umask back to 0022. This might also have the effect of opening up the permissions a bit on the lxc containers so normal users can poke around in the rootfs if they have sufficient perms (though that may not be desirable since uids will not match up properly).

Changed in juju:
status: Triaged → In Progress
assignee: nobody → Clint Byrum (clint-fewbar)
Changed in juju:
status: In Progress → Fix Committed
Changed in juju:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.