| 2010-09-22 22:37:47 |
maxadamo |
bug |
|
|
added bug |
| 2010-09-22 22:38:14 |
maxadamo |
visibility |
private |
public |
|
| 2010-09-23 14:27:13 |
maxadamo |
summary |
lxc container can power-off the host machine |
lxc container can power-off host machine |
|
| 2010-09-23 14:32:10 |
maxadamo |
description |
Binary package hint: lxc
Bug related information:
# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04
# apt-cache policy lxc
lxc:
Installed: 0.7.2-1~10.04~csz1
Candidate: 0.7.2-1~10.04~csz1
Version table:
*** 0.7.2-1~10.04~csz1 0
500 http://ppa.launchpad.net/cszikszoy/ppa/ubuntu/ lucid/main Packages
100 /var/lib/dpkg/status
0.6.5-1 0
500 http://mirror.switch.ch/ftp/mirror/ubuntu/ lucid/universe Packages
(NEVERMIND if I am using a PPA version: it's the same version you're using in Maverick and I don't think this is causing the issue that I am facing now).
I created a system image by using the tool "lxc-create" and by using the included templates (I even created images myself without this tool, nothing changes with this issue)
The tool makes all the steps to create the image (debootstrap and so on) and, at the end of the process, it creates a config file suitable for that image.
One of the last rows of the config file is:
lxc.mount.entry=proc /lxc/cont_1/rootfs/proc proc nodev,noexec,nosuid 0 0
same identical problem happens if I comment out this row and I mount /proc myself from /etc/fstab inside the container
The problem arises when I issue the command:
echo b > /proc/sysrq-trigger
In this case the host machine will power-off, and not the container.
It's possible to check what I said, without harming your server, just by running a sync command on the container:
echo b > /proc/sysrq-trigger
and checking /var/log/messages on the host server.
Right now, I have no idea how to circumvent this issue, and if this problem persist, I feel the security of LXC is heavily compromised. |
Binary package hint: lxc
Bug related information:
# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04
# apt-cache policy lxc
lxc:
Installed: 0.7.2-1~10.04~csz1
Candidate: 0.7.2-1~10.04~csz1
Version table:
*** 0.7.2-1~10.04~csz1 0
500 http://ppa.launchpad.net/cszikszoy/ppa/ubuntu/ lucid/main Packages
100 /var/lib/dpkg/status
0.6.5-1 0
500 http://mirror.switch.ch/ftp/mirror/ubuntu/ lucid/universe Packages
(NEVERMIND if I am using a PPA version: it's the same version you're using in Maverick and I don't think this is causing the issue that I am facing now).
I created a system image by using the tool "lxc-create" and by using the included templates (I even created images myself without this tool, and nothing changes with this issue)
The tool makes all the necessary steps to create the image (debootstrap and so on) and, at the end of the process, it creates a config file suitable for that image.
One of the last rows of the config file is:
lxc.mount.entry=proc /lxc/cont_1/rootfs/proc proc nodev,noexec,nosuid 0 0
same identical problem happens if I comment out this row and I mount /proc myself from /etc/fstab inside the container
The problem arises when I issue the command:
echo b > /proc/sysrq-trigger
In this case the host machine will power-off, and not the container.
It's possible to check what I said, without harming your server, just by running a sync command on the container:
echo b > /proc/sysrq-trigger
and than checking /var/log/messages on the host server. You'll see that the command is intercepted from the host and not from the container.
Right now, I have no idea how to circumvent this issue, and if this problem persist, I feel the security of LXC is heavily compromised.
|
|
| 2010-10-01 23:19:51 |
Kees Cook |
lxc (Ubuntu): status |
New |
Confirmed |
|
| 2010-10-01 23:19:56 |
Kees Cook |
lxc (Ubuntu): importance |
Undecided |
Medium |
|
| 2010-10-02 00:57:02 |
maxadamo |
description |
Binary package hint: lxc
Bug related information:
# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04
# apt-cache policy lxc
lxc:
Installed: 0.7.2-1~10.04~csz1
Candidate: 0.7.2-1~10.04~csz1
Version table:
*** 0.7.2-1~10.04~csz1 0
500 http://ppa.launchpad.net/cszikszoy/ppa/ubuntu/ lucid/main Packages
100 /var/lib/dpkg/status
0.6.5-1 0
500 http://mirror.switch.ch/ftp/mirror/ubuntu/ lucid/universe Packages
(NEVERMIND if I am using a PPA version: it's the same version you're using in Maverick and I don't think this is causing the issue that I am facing now).
I created a system image by using the tool "lxc-create" and by using the included templates (I even created images myself without this tool, and nothing changes with this issue)
The tool makes all the necessary steps to create the image (debootstrap and so on) and, at the end of the process, it creates a config file suitable for that image.
One of the last rows of the config file is:
lxc.mount.entry=proc /lxc/cont_1/rootfs/proc proc nodev,noexec,nosuid 0 0
same identical problem happens if I comment out this row and I mount /proc myself from /etc/fstab inside the container
The problem arises when I issue the command:
echo b > /proc/sysrq-trigger
In this case the host machine will power-off, and not the container.
It's possible to check what I said, without harming your server, just by running a sync command on the container:
echo b > /proc/sysrq-trigger
and than checking /var/log/messages on the host server. You'll see that the command is intercepted from the host and not from the container.
Right now, I have no idea how to circumvent this issue, and if this problem persist, I feel the security of LXC is heavily compromised.
|
Binary package hint: lxc
Bug related information:
# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04
# apt-cache policy lxc
lxc:
Installed: 0.7.2-1~10.04~csz1
Candidate: 0.7.2-1~10.04~csz1
Version table:
*** 0.7.2-1~10.04~csz1 0
500 http://ppa.launchpad.net/cszikszoy/ppa/ubuntu/ lucid/main Packages
100 /var/lib/dpkg/status
0.6.5-1 0
500 http://mirror.switch.ch/ftp/mirror/ubuntu/ lucid/universe Packages
(NEVERMIND if I am using a PPA version: it's the same version you're using in Maverick and I don't think this is causing the issue that I am facing now).
I created a system image by using the tool "lxc-create" and by using the included templates (I even created images myself without this tool, and nothing changes with this issue)
The tool makes all the necessary steps to create the image (debootstrap and so on) and, at the end of the process, it creates a config file suitable for that image.
One of the last rows of the config file is:
lxc.mount.entry=proc /lxc/cont_1/rootfs/proc proc nodev,noexec,nosuid 0 0
same identical problem happens if I comment out this row and I mount /proc myself from /etc/fstab inside the container
The problem arises when I issue the command:
echo b > /proc/sysrq-trigger
In this case the host machine will power-off, and not the container.
It's possible to check what I said, without harming your server, just by running a sync command on the container:
echo s > /proc/sysrq-trigger
and than checking /var/log/messages on the host server. You'll see that the command is intercepted from the host and not from the container.
Right now, I have no idea how to circumvent this issue, and if this problem persist, I feel the security of LXC is heavily compromised.
|
|
| 2011-04-27 15:27:05 |
Jamie Strandboge |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2011-04-27 15:31:44 |
Serge Hallyn |
lxc (Ubuntu): status |
Confirmed |
Triaged |
|
| 2011-09-28 21:48:56 |
Aaron McPhall |
bug |
|
|
added subscriber Aaron McPhall |
| 2012-03-21 14:35:13 |
Launchpad Janitor |
lxc (Ubuntu): status |
Triaged |
Fix Released |
|
| 2012-03-21 15:08:21 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lxc |
|
| 2013-02-27 06:24:57 |
Qiu Yu |
bug |
|
|
added subscriber unicell |
