Re: [lxc-devel] About to tag alpha-2
On Tue, 2014-09-30 at 18:00 -0400, Michael H. Warfield wrote: On Tue, 2014-09-30 at 15:56 -0400, Stéphane Graber wrote: Hey everyone, So just wanted to let you know that current git master is the alpha-2 candidate. If you have some time today/tonight, please grab git master and test it to find any major issue which we shouldn't release alpha-2 with. We have two open buzilla reports, one at Debian and one at Fedora that are flagged as security issues due to fixed, predicatable, user ids and passwords in the containers created from the live templates. Can we get these issues addressed? In a distro, that would be a hard stop critical dependency. I would throw a blocker on that alone just to get two security reports off our desks. If there's no report of such issue by tomorrow morning, I'll tag alpha-2 and then we'll resume landing changes into git master. Thanks everyone who's contributed to LXC 1.1 so far and sorry for not releasing an alpha earlier, I'd been postponing most of it due for the systemd changes and those took longer to figure out than expected. Surprise, surprise... Has the lxc.kmsg thing and systemd-journald going rogue been sorted? Dwight has had it covered in Oracle and I'm trying to cover it in a pending patch for Fedora and CentOS. Is there anything I've missed or Dwight has missed in the rpm camps (Oracle, Fedora, CentOS, SUSE)? Oh, duh... You are referring to the init script and rpm fixes that I put together as the systemd changes. I wasn't thinking clearly about that last night since it was. Disregard that last remark, yeah. My last set of changes for the templates is also systemd related er the systemd-journald problem. Regards, Mike Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | 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 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
Responding to my own hasty post from last night... On Tue, 2014-09-30 at 17:13 -0400, Michael H. Warfield wrote: Sorry, I was completely out of touch from the net for several days and then I totally missed this when I got back... I should have responded to this days ago... Sigh... On Fri, 2014-09-19 at 17:15 -0400, Stéphane Graber wrote: On Sun, Sep 14, 2014 at 08:57:58PM -0400, Michael H. Warfield wrote: Various fixes for Fedora/CentOS/OpenSUSE templates and systemd. This patch integrates several fixes for several template issues and open bugzilla bugs at the Fedora project. The lxc-centos template now supports CentOS 7 and correct configuration of systemd in CentOS. The CentOS and Fedora template have been fixed for a rootfs bug that was a skew between the parsed parameter (rootfs) and the working variable (rootfs_path) by normalizing to rootfs, congruent with several other templates. This should fix the backing store problem. The user password generation logic has been refactored out of the Fedora and CentOS templates into a new template/functions file. This is the beginning of a security fix that has been reported as a bug in Fedora and Debian. The functions support random password generation and/or disabled password on accounts. Templates need to convert over and avoid static passwords like root:root or ubuntu:ubuntu in order to avoid this security issue. Function supports multiple user setup. The template/functions file includes a function for static MAC address generation (not yet used) and may contain other common functions we standardize on. Can we stop including MAc address generation everywhere now that we have the MAC address templating stuff done in C? :) Does no harm and I'm still running into the perpetual recreate new Mac addresses on my Ubuntu containers (which screws up IPv6 royally). Probably because I have an old default and older containers but I don't particularly mind double fixing something like this... The function is there in a common location but it's not currently called by anything and I've left the current generating logic in the templates themselves alone, so there was no change there at all. Pull that little function if you like but it won't make any difference to any live code, since it's not currently called. Added fedora user to lxc-fedora template. Added centos user to lxc-centos template. Dropping setfcap has been moved to a comment for Fedora, CentOS, and SUSE due to it's interference with yum update in containers (yum fails to update several packages including httpd). Added sudo to the package list for CentOS and Fedora. Set the apparmor profile for CentOS, Fedora, and SUSE containers to unconfined, until someone comes up with something better, in order to have containers run out of the box on apparmor hosts. Commented code in the individual templates has been moved to explicit settings in the common config files. From a security point of view, I much prefer things to fail badly than be able to wreak havoc on my system, so I'd prefer we don't do that. This came up months ago and there was all sorts of discussions over on the -user list of profiles and options and I even pinged you and Serge in private E-Mail asking if a consensus was agreed on. All I got were crickets and, in the mean time, we still have failing containers. We got nowhere then. Where are we now? It's been months. In the absence of any more constructive solutions or feedback, I went with this. I don't use apparmour so I can't test or resolve the problem and I have no better solution. Failing badly is an understatement and we have had complaints and we have no better solution to the complaints. Instead, let's land the rest of your systemd fixes and then I can spend a few minutes figure out exactly what's failing when running on current Ubuntu and come up with a proper profile for it which still prevents most of the usual issues (proc, sys, ...). Ah, ok, you're going to look into is, I see. That's good. Ok, but we need something in the next cuts of both 1.1 and 1.0. The gods-be-damned systemd-journald is causing bugzilla bug reports (one report was complaining of CPU heating problems from that nonsense) and the password problem is the subject of bugzilla security reports in both Fedora and Debian that I can't even begin to address till we move forward on this (CentOS and Fedora are fine... I'll fix the others if I have to just to clear the security flags). I've cleared a few bugzilla reports over at the Fedora but I would really like to clear these things that are flagged as security issues. Addressed systemd-journald runaway CPU issue by setting lxc.kmsg = 0 in affected template (including Mandriva) and establishing a run time default to autoswitch lxc.kmsg depending on the state of
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
2014-10-01 14:15 GMT+02:00 Michael H. Warfield m...@wittsend.com: This bug is now closed, after I explained to the originator what the problem was, but it points out the problem we're seeing from having kmsg being a symlink to console and having journald run crazy in the container... https://bugzilla.redhat.com/show_bug.cgi?id=1141456 Just ftr, this bug is not closed, and it should not be, because the patches have not yet landed in an LXC release (unless I am missing something) and thus are also not present in the Fedora/EPEL RPMs. - Thomas ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
On Wed, Oct 01, 2014 at 08:15:04AM -0400, Michael H. Warfield wrote: Responding to my own hasty post from last night... On Tue, 2014-09-30 at 17:13 -0400, Michael H. Warfield wrote: Sorry, I was completely out of touch from the net for several days and then I totally missed this when I got back... I should have responded to this days ago... Sigh... On Fri, 2014-09-19 at 17:15 -0400, Stéphane Graber wrote: On Sun, Sep 14, 2014 at 08:57:58PM -0400, Michael H. Warfield wrote: Various fixes for Fedora/CentOS/OpenSUSE templates and systemd. This patch integrates several fixes for several template issues and open bugzilla bugs at the Fedora project. The lxc-centos template now supports CentOS 7 and correct configuration of systemd in CentOS. The CentOS and Fedora template have been fixed for a rootfs bug that was a skew between the parsed parameter (rootfs) and the working variable (rootfs_path) by normalizing to rootfs, congruent with several other templates. This should fix the backing store problem. The user password generation logic has been refactored out of the Fedora and CentOS templates into a new template/functions file. This is the beginning of a security fix that has been reported as a bug in Fedora and Debian. The functions support random password generation and/or disabled password on accounts. Templates need to convert over and avoid static passwords like root:root or ubuntu:ubuntu in order to avoid this security issue. Function supports multiple user setup. The template/functions file includes a function for static MAC address generation (not yet used) and may contain other common functions we standardize on. Can we stop including MAc address generation everywhere now that we have the MAC address templating stuff done in C? :) Does no harm and I'm still running into the perpetual recreate new Mac addresses on my Ubuntu containers (which screws up IPv6 royally). Probably because I have an old default and older containers but I don't particularly mind double fixing something like this... The function is there in a common location but it's not currently called by anything and I've left the current generating logic in the templates themselves alone, so there was no change there at all. Pull that little function if you like but it won't make any difference to any live code, since it's not currently called. Added fedora user to lxc-fedora template. Added centos user to lxc-centos template. Dropping setfcap has been moved to a comment for Fedora, CentOS, and SUSE due to it's interference with yum update in containers (yum fails to update several packages including httpd). Added sudo to the package list for CentOS and Fedora. Set the apparmor profile for CentOS, Fedora, and SUSE containers to unconfined, until someone comes up with something better, in order to have containers run out of the box on apparmor hosts. Commented code in the individual templates has been moved to explicit settings in the common config files. From a security point of view, I much prefer things to fail badly than be able to wreak havoc on my system, so I'd prefer we don't do that. This came up months ago and there was all sorts of discussions over on the -user list of profiles and options and I even pinged you and Serge in private E-Mail asking if a consensus was agreed on. All I got were crickets and, in the mean time, we still have failing containers. We got nowhere then. Where are we now? It's been months. In the absence of any more constructive solutions or feedback, I went with this. I don't use apparmour so I can't test or resolve the problem and I have no better solution. Failing badly is an understatement and we have had complaints and we have no better solution to the complaints. Instead, let's land the rest of your systemd fixes and then I can spend a few minutes figure out exactly what's failing when running on current Ubuntu and come up with a proper profile for it which still prevents most of the usual issues (proc, sys, ...). Ah, ok, you're going to look into is, I see. That's good. Yeah, we'll also need that to run Ubuntu+systemd itself inside LXC, what we need to figure out is what bits are safe to allow in the apparmor profile and what bits are just plain wrong and need to be fixed in systemd. Ok, but we need something in the next cuts of both 1.1 and 1.0. The gods-be-damned systemd-journald is causing bugzilla bug reports (one report was complaining of CPU heating problems from that nonsense) and the password problem is the subject of bugzilla security reports in both Fedora and Debian that I can't even begin to address till we move forward on this (CentOS and Fedora are fine... I'll fix the others if I have
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
On Wed, 2014-10-01 at 17:25 +0200, Thomas Moschny wrote: 2014-10-01 14:15 GMT+02:00 Michael H. Warfield m...@wittsend.com: This bug is now closed, after I explained to the originator what the problem was, but it points out the problem we're seeing from having kmsg being a symlink to console and having journald run crazy in the container... https://bugzilla.redhat.com/show_bug.cgi?id=1141456 Just ftr, this bug is not closed, and it should not be, because the patches have not yet landed in an LXC release (unless I am missing something) and thus are also not present in the Fedora/EPEL RPMs. Ah crap. You're right. It was the other one, about lxc-stop and a debian container, that the original poster closed after I pointed him at the fix. This one is still open, you're absolutely correct. Thank you! - Thomas Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | 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 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote: [snip] Would this be better if this paralleled autodev an we only disabled kmsg by default if and when systemd was detected as the init system? The situation is very analogous to the autodev situation. If a user were to switch from say upstart to systemd and autodev is not specified in the config, we default that to enabled when we detect systemd as the init system at run time. We could also default kmsg to 0 in the case of systemd being the run time init system manager to prevent journald from going into it's console message loop and burning CPU. Would that work better for you? Since you can switch init systems from within the container and may not have access to the container config file that's in the host, something should be done to cover the run time case, like we do with autodev. That's what I was attempting to do... I'm not very much fond of having to do per-init system config changes but yeah, that sounds like a reasonable way to go. If we start getting more and more of those cases we may want to make things slightly more configurable by just having LXC include some default configuration files based on that detection. Oh? Sort of like conditional includes? If lxc.init = systemd include systemd.conf sort of thing? It would have to be runtime conditional but that does make some sense at that. This bug is now closed, after I explained to the originator what the problem was, but it points out the problem we're seeing from having kmsg being a symlink to console and having journald run crazy in the container... https://bugzilla.redhat.com/show_bug.cgi?id=1141456 -- (1) Starting a basic LXC container, which is not configured to do anything at all, *immediately* (and without delay) raises the temperature *substantially* of one of the cores. (2) Starting a second LXC container (also not configured to do anything), does the same as (1), but on a different core (i.e. the one that that LXC uses). -- [Big snip - this time I remembered...] Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | 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 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:
[snip]
Would this be better if this paralleled autodev an we only disabled kmsg
by default if and when systemd was detected as the init system? The
situation is very analogous to the autodev situation. If a user were to
switch from say upstart to systemd and autodev is not specified in the
config, we default that to enabled when we detect systemd as the init
system at run time. We could also default kmsg to 0 in the case of
systemd being the run time init system manager to prevent journald from
going into it's console message loop and burning CPU. Would that work
better for you? Since you can switch init systems from within the
container and may not have access to the container config file that's in
the host, something should be done to cover the run time case, like we
do with autodev. That's what I was attempting to do...
I'm not very much fond of having to do per-init system config changes
but yeah, that sounds like a reasonable way to go.
If we start getting more and more of those cases we may want to make
things slightly more configurable by just having LXC include some
default configuration files based on that detection.
Oh? Sort of like conditional includes? If lxc.init = systemd include
systemd.conf sort of thing? It would have to be runtime conditional but
that does make some sense at that.
So I see a few ways of doing it:
0) We keep all the logic hardcoded as it is today for autodev.
1) We keep your detection code and simply call
load_config(/usr/share/lxc/config/init-system.conf) before parsing
anything else, so the container's own config will override anything
that's in there.
2) We make our parser support conditionals and export init_system as a
variable so that we can have the default distro configs do things like:
[init_system==systemd] lxc.include =
/usr/share/lxc/config/systemd.common.conf
[privileged==false] lxc.include = /usr/share/lxc/config/unpriv.common.conf
This would be more flexible and allow for the addition of extra
variables later on. It'd also allow switching between privileged and
unprivileged and between init systems without configuration changes.
3) We do a slightly simpler version of the above by adding two things:
- Simple variables, like ${init_system} and ${runtime_mode} and
allow using them in the config with the parser replacing them with the
right thing at parsing time.
- Add a @ keyword which when placed at the beginning of the line
will tell the parser to ignore any failure caused by the line in
question.
This then allows us to put things like:
@lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
@lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf
And not have the parser fail if I somehow decide to run OpenRC as my
container's init system without an existing ubuntu.openrc.conf.
This bug is now closed, after I explained to the originator what the
problem was, but it points out the problem we're seeing from having kmsg
being a symlink to console and having journald run crazy in the
container...
https://bugzilla.redhat.com/show_bug.cgi?id=1141456
--
(1) Starting a basic LXC container, which is not configured to do
anything at all, *immediately* (and without delay) raises the
temperature *substantially* of one of the cores.
(2) Starting a second LXC container (also not configured to do
anything), does the same as (1), but on a different core (i.e. the one
that that LXC uses).
--
[Big snip - this time I remembered...]
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | 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!
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
On Wed, 2014-10-01 at 12:06 -0400, Stéphane Graber wrote:
On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:
[snip]
Would this be better if this paralleled autodev an we only disabled kmsg
by default if and when systemd was detected as the init system? The
situation is very analogous to the autodev situation. If a user were to
switch from say upstart to systemd and autodev is not specified in the
config, we default that to enabled when we detect systemd as the init
system at run time. We could also default kmsg to 0 in the case of
systemd being the run time init system manager to prevent journald from
going into it's console message loop and burning CPU. Would that work
better for you? Since you can switch init systems from within the
container and may not have access to the container config file that's in
the host, something should be done to cover the run time case, like we
do with autodev. That's what I was attempting to do...
I'm not very much fond of having to do per-init system config changes
but yeah, that sounds like a reasonable way to go.
If we start getting more and more of those cases we may want to make
things slightly more configurable by just having LXC include some
default configuration files based on that detection.
Oh? Sort of like conditional includes? If lxc.init = systemd include
systemd.conf sort of thing? It would have to be runtime conditional but
that does make some sense at that.
So I see a few ways of doing it:
0) We keep all the logic hardcoded as it is today for autodev.
1) We keep your detection code and simply call
load_config(/usr/share/lxc/config/init-system.conf) before parsing
anything else, so the container's own config will override anything
that's in there.
2) We make our parser support conditionals and export init_system as a
variable so that we can have the default distro configs do things like:
[init_system==systemd] lxc.include =
/usr/share/lxc/config/systemd.common.conf
[privileged==false] lxc.include = /usr/share/lxc/config/unpriv.common.conf
This would be more flexible and allow for the addition of extra
variables later on. It'd also allow switching between privileged and
unprivileged and between init systems without configuration changes.
3) We do a slightly simpler version of the above by adding two things:
- Simple variables, like ${init_system} and ${runtime_mode} and
allow using them in the config with the parser replacing them with the
right thing at parsing time.
- Add a @ keyword which when placed at the beginning of the line
will tell the parser to ignore any failure caused by the line in
question.
This then allows us to put things like:
@lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
@lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf
And not have the parser fail if I somehow decide to run OpenRC as my
container's init system without an existing ubuntu.openrc.conf.
Ok... Option 0 is just about recoded so that the default kmsg is
dependent on systemd and not merely autodev. I've turned
check_autodev into check_systemd and conditionalized both autodev
and kmsg based on that return value, dependent on any explicitly set
value. For the short term, that appears to be the quickest and easiest.
Option 3 sounds like a good versatile long term option but we still need
some runtime autodetection of some of those values. Where does that
${init_system} come from? Since container owners can internally change
their run-time configuration to switch init system manager and then
reboot the container, something needs to be detected at runtime or the
container could end up being configured in ways that degrade the
performance or behavior of the host. Even then, we still might have a
gap in the reboot process if the configuration is not reevaluated when
the container is rebooted (aot shut down and restarted).
Not sure if I care that much for option #1. #2 would be my second
choice for a long term strategy with the proviso that we have some sort
of runtime detection.
Regards,
Mike
This bug is now closed, after I explained to the originator what the
problem was, but it points out the problem we're seeing from having kmsg
being a symlink to console and having journald run crazy in the
container...
https://bugzilla.redhat.com/show_bug.cgi?id=1141456
--
(1) Starting a basic LXC container, which is not configured to do
anything at all, *immediately* (and without delay) raises the
temperature *substantially* of one of the cores.
(2) Starting a second LXC container (also not configured to do
anything), does the same as (1), but on a different core (i.e. the
one that
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
Quoting Stéphane Graber (stgra...@ubuntu.com): On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote: On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote: [snip] Would this be better if this paralleled autodev an we only disabled kmsg by default if and when systemd was detected as the init system? The situation is very analogous to the autodev situation. If a user were to switch from say upstart to systemd and autodev is not specified in the config, we default that to enabled when we detect systemd as the init system at run time. We could also default kmsg to 0 in the case of systemd being the run time init system manager to prevent journald from going into it's console message loop and burning CPU. Would that work better for you? Since you can switch init systems from within the container and may not have access to the container config file that's in the host, something should be done to cover the run time case, like we do with autodev. That's what I was attempting to do... I'm not very much fond of having to do per-init system config changes but yeah, that sounds like a reasonable way to go. If we start getting more and more of those cases we may want to make things slightly more configurable by just having LXC include some default configuration files based on that detection. Oh? Sort of like conditional includes? If lxc.init = systemd include systemd.conf sort of thing? It would have to be runtime conditional but that does make some sense at that. So I see a few ways of doing it: 0) We keep all the logic hardcoded as it is today for autodev. Can we get a list of the things which need to be different? AFAICS the lxc.autodev needs work, but once that work is done would be fine for non-systemd hosts. Currently, on an ubuntu system for unpriv users we have lxc.mount.entry entries for basic devices which get bind-mounted from the host. The lxc.autodev case would simply be 1. create .local/share/lxc/container/rootfs.dev 2. at container start, a. bind-mount .local/share/lxc/container/rootfs.dev to .local/share/lxc/container/rootfs.dev/rootfs/dev b. for device in console full null random tty urandom zero; do bind mount /dev/$device .local/share/lxc/container/rootfs.dev/$device (creating the file if needed) if lxc.autodev does this, is there any reason not to make autodev the default? ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc]
Branch: refs/tags/lxc-1.1.0.alpha2 Home: https://github.com/lxc/lxc ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] e35682: change version to 1.1.0.alpha1 in configure.ac
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: e356822da479b77c21b02119bcc96c915f8ddbee https://github.com/lxc/lxc/commit/e356822da479b77c21b02119bcc96c915f8ddbee Author: Stéphane Graber stgra...@ubuntu.com Date: 2014-10-01 (Wed, 01 Oct 2014) Changed paths: M configure.ac Log Message: --- change version to 1.1.0.alpha1 in configure.ac Signed-off-by: Stéphane Graber stgra...@ubuntu.com ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [lxc/lxc] e35682: change version to 1.1.0.alpha1 in configure.ac
Gah, that obviously was meant to read alpha-2... bad copy/paste. On Wed, Oct 01, 2014 at 11:24:37AM -0700, GitHub wrote: Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: e356822da479b77c21b02119bcc96c915f8ddbee https://github.com/lxc/lxc/commit/e356822da479b77c21b02119bcc96c915f8ddbee Author: Stéphane Graber stgra...@ubuntu.com Date: 2014-10-01 (Wed, 01 Oct 2014) Changed paths: M configure.ac Log Message: --- change version to 1.1.0.alpha1 in configure.ac Signed-off-by: Stéphane Graber stgra...@ubuntu.com ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Passed: lxc/lxc#692 (lxc-1.1.0.alpha2 - e356822)
Build Update for lxc/lxc - Build: #692 Status: Passed Duration: 2 minutes and 54 seconds Commit: e356822 (lxc-1.1.0.alpha2) Author: Stéphane Graber Message: change version to 1.1.0.alpha1 in configure.ac Signed-off-by: Stéphane Graber stgra...@ubuntu.com View the changeset: https://github.com/lxc/lxc/compare/lxc-1.1.0.alpha2 View the full build log and details: https://travis-ci.org/lxc/lxc/builds/36798357 -- You can configure recipients for build notifications in your .travis.yml file. See http://docs.travis-ci.com/user/notifications ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/1] pivot_root: switch to a new mechanism (v2)
On Mon, 29 Sep 2014 22:46:26 + Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Andy Lutomirski (l...@amacapital.net): On Mon, Sep 29, 2014 at 2:46 PM, Serge Hallyn serge.hal...@ubuntu.com wrote: I'm not sure that / is well-defined. You have oldroot mounted on Whoa. Seems you're right. I would have expected it to mean precisely the dentry+vfsmount which I pivot-rooted to. Which have been overmounted, so umount(/) would umount what's been mounted over them. top of newroot, and / refers to one of them (presumably oldroot on newer kernels, and maybe newroot on older kernels). So it seems. I think that you want to unmount oldroot, leaving only newroot mounted. When you call umount2, . reliably refers to oldroot. Right /me wonders whether there's a vulnerability here on new kernels if the test were adjusted a bit. mnt_ns oughtn't to be NULL, right? Wouldn't it be in the older kernels though? That's where mnt_ns ends up being null. So from 3.8..3.11 an unpriv user (though CLONE_NEWUSER) can do a pivot_root causing null MNT_NS, and presumably find an interesting way to dereference it. Yeah the mnt_ns being NULL seems strange to me, but I can't tell if that is by design or not. The commit that changed the behavior between 3.11 and 3.12 is: 8033426e6bdb2690d302 vfs: allow umount to handle mountpoints without revalidating them I added some printk debugging to see what was going on. So prior to this change it looks like the umount2(/, MNT_DETACH) isn't really working such that doing the kern_path() walk in do_mount() afterwards gets you back to the same struct mount whose mnt_ns field was NULL'ed out by the umount2. After the above change, its a different struct mount (with a non-NULL mnt_ns) and thus the check_mnt(parent) in do_add_mount() works and a mount can succeed. However, I didn't see how having a NULL mnt_ns could be exploited, in fact it looks like to me the code is setup to handle mnt-mnt_ns being NULL (ie, see IS_MNT_NEW()) but someone who understands the namespace code better than me could probably say. I'm currently having trouble finding an old enough box. Can you try the attached fancier test and see what it prints? Exact same as mine: ubuntu@kvm-p3:~$ sudo ./x pivoted in new root I am 1441 root@kvm-p3:/# mount --bind /mnt /mnt Ah, OK, I completely misunderstood your original email. If I change umount2 to umount . instead of / in my code, the subsequent mount --bind works for me on 3.2. Same here, so I can push a fix for lxc - thanks! FWIW, your test does awful, awful things if I don't do the MS_PRIVATE thing on top. D'oh. Sorry about that. -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
On Wed, 2014-10-01 at 14:18 -0400, Stéphane Graber wrote:
On Wed, Oct 01, 2014 at 12:41:26PM -0400, Michael H. Warfield wrote:
On Wed, 2014-10-01 at 12:06 -0400, Stéphane Graber wrote:
On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:
[snip]
Would this be better if this paralleled autodev an we only disabled
kmsg
by default if and when systemd was detected as the init system? The
situation is very analogous to the autodev situation. If a user
were to
switch from say upstart to systemd and autodev is not specified in
the
config, we default that to enabled when we detect systemd as the
init
system at run time. We could also default kmsg to 0 in the case of
systemd being the run time init system manager to prevent journald
from
going into it's console message loop and burning CPU. Would that
work
better for you? Since you can switch init systems from within the
container and may not have access to the container config file
that's in
the host, something should be done to cover the run time case, like
we
do with autodev. That's what I was attempting to do...
I'm not very much fond of having to do per-init system config changes
but yeah, that sounds like a reasonable way to go.
If we start getting more and more of those cases we may want to make
things slightly more configurable by just having LXC include some
default configuration files based on that detection.
Oh? Sort of like conditional includes? If lxc.init = systemd include
systemd.conf sort of thing? It would have to be runtime conditional but
that does make some sense at that.
So I see a few ways of doing it:
0) We keep all the logic hardcoded as it is today for autodev.
1) We keep your detection code and simply call
load_config(/usr/share/lxc/config/init-system.conf) before parsing
anything else, so the container's own config will override anything
that's in there.
2) We make our parser support conditionals and export init_system as a
variable so that we can have the default distro configs do things
like:
[init_system==systemd] lxc.include =
/usr/share/lxc/config/systemd.common.conf
[privileged==false] lxc.include =
/usr/share/lxc/config/unpriv.common.conf
This would be more flexible and allow for the addition of extra
variables later on. It'd also allow switching between privileged and
unprivileged and between init systems without configuration changes.
3) We do a slightly simpler version of the above by adding two things:
- Simple variables, like ${init_system} and ${runtime_mode} and
allow using them in the config with the parser replacing them with
the
right thing at parsing time.
- Add a @ keyword which when placed at the beginning of the line
will tell the parser to ignore any failure caused by the line in
question.
This then allows us to put things like:
@lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
@lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf
And not have the parser fail if I somehow decide to run OpenRC as my
container's init system without an existing ubuntu.openrc.conf.
Ok... Option 0 is just about recoded so that the default kmsg is
dependent on systemd and not merely autodev. I've turned
check_autodev into check_systemd and conditionalized both autodev
and kmsg based on that return value, dependent on any explicitly set
value. For the short term, that appears to be the quickest and easiest.
Option 3 sounds like a good versatile long term option but we still need
some runtime autodetection of some of those values. Where does that
${init_system} come from? Since container owners can internally change
their run-time configuration to switch init system manager and then
reboot the container, something needs to be detected at runtime or the
container could end up being configured in ways that degrade the
performance or behavior of the host. Even then, we still might have a
gap in the reboot process if the configuration is not reevaluated when
the container is rebooted (aot shut down and restarted).
Not sure if I care that much for option #1. #2 would be my second
choice for a long term strategy with the proviso that we have some sort
of runtime detection.
There would be a list of variables which LXC exposes to the config
parser, so LXC would still do the init system detection as it does
today, though possibly add detection for a few more init systems and
then set init_system accordingly before passing it to the parser. Same
goes for runtime_mode, LXC would set this to
