Re: [Lxc-users] [PATCH] Re: read only rootfs
On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
Unfortunately, I also still find that if there's a -o remount,ro in the
halt/reboot script, it still sets /dev/pts to ro and that still
propagates to the host and to the other containers triggering random
Wow.
Did a quick grep; is there any reason why lxc-start doesn't turn on
MS_SLAVE for the client's root? Something like:
From 7fbc3ec940403605c53b253d8630c3f47fad154c Mon Sep 17 00:00:00 2001
From: Serge Hallyn serge.hal...@ubuntu.com
Date: Mon, 18 Jul 2011 07:29:57 -0500
Subject: [PATCH 1/1] (untested) turn container rootfs into MS_SLAVE
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 2eb598b..d36fe47 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -732,6 +732,11 @@ static int setup_rootfs(const struct lxc_rootfs *rootfs)
return -1;
}
+ if (mount(rootfs-path, rootfs-path, none, MS_SLAVE, 0)) {
+ ERROR(failed to turn child rootfs into slave);
+ return -1;
+ }
+
DEBUG(mounted '%s' on '%s', rootfs-path, rootfs-mount);
return 0;
--
1.7.4.1
Problem...
lxc-start 1311083210.678 ERRORlxc_conf - failed to turn child rootfs
into slave
lxc-start 1311083210.678 ERRORlxc_conf - failed to setup rootfs for
'Alcove'
lxc-start 1311083210.678 ERRORlxc_start - failed to setup the
container
lxc-start 1311083210.679 ERRORlxc_sync - invalid sequence number 1.
expected 2
lxc-start 1311083210.679 ERRORlxc_start - failed to spawn 'Alcove'
This may be do to the way I have my rootfs set up. Mine are bind mounts
from a private area to the common mount point. I've noticed that inside
the containers, I see my root file system show up twice like this (over
on one of my production machines):
[mhw@Berserker ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 480719056 404550544 51749312 89% /
/dev/sdb1480719056 404550544 51749312 89% /
/dev/sdc1480719056202816 456097040 1% /export
/dev/sda7693727244 624715768 33772100 95% /srv/shared
none 1030612 0 1030612 0% /dev/shm
[mhw@berserker-base ~]$ cat /srv/lxc/config/Berserker.fstab
/srv/lxc/private/Berserker /srv/lxc/rootfs none bind 0 0
/export /srv/lxc/rootfs/exportnone bind 0 0
/home/shared /srv/lxc/rootfs/srv/sharednone bind 0 0
Maybe not such a good idea (mine)?
Regards,
Mike
The kernel should also prohibit, totally, the propagation of remount
The kernel doesn't know about containers, so it's up to userspace :)
-serge
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [PATCH] Re: read only rootfs
On Tue, 2011-07-19 at 09:55 -0400, Michael H. Warfield wrote:
On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
Unfortunately, I also still find that if there's a -o remount,ro in the
halt/reboot script, it still sets /dev/pts to ro and that still
propagates to the host and to the other containers triggering random
Wow.
Did a quick grep; is there any reason why lxc-start doesn't turn on
MS_SLAVE for the client's root? Something like:
From 7fbc3ec940403605c53b253d8630c3f47fad154c Mon Sep 17 00:00:00 2001
From: Serge Hallyn serge.hal...@ubuntu.com
Date: Mon, 18 Jul 2011 07:29:57 -0500
Subject: [PATCH 1/1] (untested) turn container rootfs into MS_SLAVE
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 2eb598b..d36fe47 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -732,6 +732,11 @@ static int setup_rootfs(const struct lxc_rootfs
*rootfs)
return -1;
}
+ if (mount(rootfs-path, rootfs-path, none, MS_SLAVE, 0)) {
+ ERROR(failed to turn child rootfs into slave);
+ return -1;
+ }
+
DEBUG(mounted '%s' on '%s', rootfs-path, rootfs-mount);
return 0;
--
1.7.4.1
Problem...
lxc-start 1311083210.678 ERRORlxc_conf - failed to turn child
rootfs into slave
lxc-start 1311083210.678 ERRORlxc_conf - failed to setup rootfs for
'Alcove'
lxc-start 1311083210.678 ERRORlxc_start - failed to setup the
container
lxc-start 1311083210.679 ERRORlxc_sync - invalid sequence number 1.
expected 2
lxc-start 1311083210.679 ERRORlxc_start - failed to spawn 'Alcove'
This may be do to the way I have my rootfs set up. Mine are bind mounts
from a private area to the common mount point. I've noticed that inside
the containers, I see my root file system show up twice like this (over
on one of my production machines):
Or, maybe not. Tried specifying the private directory as the rootfs
mount point directly and still got the same error, no bind mount in
fstab involved. :-P
Mike
Snip
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [PATCH] Re: read only rootfs
On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
Unfortunately, I also still find that if there's a -o remount,ro in the
halt/reboot script, it still sets /dev/pts to ro and that still
propagates to the host and to the other containers triggering random
Wow.
Did a quick grep; is there any reason why lxc-start doesn't turn on
MS_SLAVE for the client's root? Something like:
From 7fbc3ec940403605c53b253d8630c3f47fad154c Mon Sep 17 00:00:00 2001
From: Serge Hallyn serge.hal...@ubuntu.com
Date: Mon, 18 Jul 2011 07:29:57 -0500
Subject: [PATCH 1/1] (untested) turn container rootfs into MS_SLAVE
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 2eb598b..d36fe47 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -732,6 +732,11 @@ static int setup_rootfs(const struct lxc_rootfs *rootfs)
return -1;
}
+ if (mount(rootfs-path, rootfs-path, none, MS_SLAVE, 0)) {
+ ERROR(failed to turn child rootfs into slave);
+ return -1;
+ }
+
DEBUG(mounted '%s' on '%s', rootfs-path, rootfs-mount);
return 0;
--
1.7.4.1
I poked at this some more.
First, I stuck a perror in that if check right after the mount to find
out what it was griping about...
[root@forest SPECS]# lxc-start --name Alcove
setup_rootfs, MS_SLAVE: Invalid argument
lxc-start: failed to turn child rootfs into slave
lxc-start: failed to setup rootfs for 'Alcove'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'Alcove'
Yuck. Invalid argument? Then I started thinking... Wasn't something
missing in that command. Wouldn't you need those flags to be
MS_REMOUNT | MS_SLAVE since you're remounting? Tried that. No joy.
Same error.
Sooo... I looked up at mount_rootfs called from the stanza above it.
Tried adding the MS_SLAVE to the mount command proper in
mount_rootfs_dir and commenting out the remount block entirely. The
file system mounts properly but adding MS_SLAVE didn't solve the
problem. :-P That should have been the right spot.
Then I noticed a discrepancy. In mount_rootfs_dir mount it called with
path and target while back in setup_rootfs the remount is calling it
with path and path. Ah ha... So I changed that mount to read like
this:
if (mount(rootfs-path, rootfs-mount, none, MS_REMOUNT|MS_SLAVE, 0)) {
Again. Fixed the code but not the problem.
I think the problem is that you are only doing this on the rootfs and
that flag does not automagically propagate to the submounts. That's
sort of implied by the way the man page for the mount command reads. It
doesn't mention a slave option on individual file systems but has a
--make-rslave function which recursively makes that mountpoint and all
its submountpoints into slaves. Tried running mount
--make-slave /dev/pts in the container and didn't get an error but still
didn't fix the problem but I figured that would be too easy and it
needed to be done back in lxc proper.
At that point, I went through src/lxc/conf.c and added MS_SLAVE to every
mount call. Yes, overly aggressive but just for a shotgun test. It
ran. But still failed the test. If I remount /dev/pts as ro in the
container, I still get it ro in the host. Then remount rw in the
container and it's back to rw in the host. Is this a kernel bug or what
am I missing here?
Strange too (and I just noticed this) is that I have two mount instances
of devpts on /dev/pts:
[root@alcove mhw]# mount -t devpts
devpts on /dev/console type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/tty1 type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/tty2 type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/tty3 type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/tty4 type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/tty5 type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/tty6 type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=666)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=666)
I don't have any devpts mounts in either the container /etc/fstab, the
fstab lxc is referencing, or in any lxc.mount.entry in the config file.
Why are there two of them there and is that indicative of a problem?
Regards,
Mike
The kernel should also prohibit, totally, the propagation of remount
The kernel doesn't know about containers, so it's up to userspace :)
-serge
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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
Re: [Lxc-users] [PATCH] Re: read only rootfs
On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
Unfortunately, I also still find that if there's a -o remount,ro in the
halt/reboot script, it still sets /dev/pts to ro and that still
propagates to the host and to the other containers triggering random
Wow.
Did a quick grep; is there any reason why lxc-start doesn't turn on
MS_SLAVE for the client's root? Something like:
From 7fbc3ec940403605c53b253d8630c3f47fad154c Mon Sep 17 00:00:00 2001
From: Serge Hallyn serge.hal...@ubuntu.com
Date: Mon, 18 Jul 2011 07:29:57 -0500
Subject: [PATCH 1/1] (untested) turn container rootfs into MS_SLAVE
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 2eb598b..d36fe47 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -732,6 +732,11 @@ static int setup_rootfs(const struct lxc_rootfs *rootfs)
return -1;
}
+ if (mount(rootfs-path, rootfs-path, none, MS_SLAVE, 0)) {
+ ERROR(failed to turn child rootfs into slave);
+ return -1;
+ }
+
DEBUG(mounted '%s' on '%s', rootfs-path, rootfs-mount);
return 0;
--
1.7.4.1
The kernel should also prohibit, totally, the propagation of remount
The kernel doesn't know about containers, so it's up to userspace :)
Acceptable and that's reasonable. But, for security and integrity
reasons, it has to be the host / parent user space not the guest / child
user space which can make that decision. And it has to be the default.
Anything less is a security vulnerability.
-serge
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
