[lxc-devel] [critical] "Default" configuration may destroy host system

Andrian Nord nightnord at gmail.com
Tue Nov 24 22:10:14 UTC 2009


On Tue, Nov 24, 2009 at 10:28:24PM +0100, Daniel Lezcano wrote:
> I am hesitating to say "root should know what it does".

Yes, he should, but root may also make a typo ;)

> Yeah, maybe it would be preferable to move the "rcfile" parsing from the 
> lxc_start function to the caller and pass the "struct lxc_conf" to 
> lxc_start. So we have the lxc_conf structure in lxc_start and we can do 
> all the sanity check before calling lxc_start, no ?

You mean - parse rcfile before spawning, i.e. in hosts's namespace? Good
idea, at least if something will lead to segfault it would be seen
directly, instead of silent don't-know-what-happens =)

> I am not sure to understand what you mean by overriding 'default setting 
> with command line switches'.
> Can you elaborate a bit with an example ?

I've already talking about that, in "General lxc architecture" thread or
something like that.

I'm about possiblity of using something like that

lxc-start -f /path/to/some/common/rcfile --define lxc.rootfs=/lxc/root/tmp \
		--define lxc.network.ipv4=1.2.3.4/24 --name tmp1

Of course, as it was already said in other thread, it's possible to use

echo -e "$(cat /path/to/some/common/rcfile)\nlxc.rootfs=/lxc/root/tmp" \
	| lxc-start -f /proc/self/fd/0 --name tmp1

But that's probably a dirty trick =)

Anyway, that's not so important to consider by now

> Do you mind if I move the rcfile parsing before calling lxc_start and 
> then we discuss about the sanity checks in lxc_start ?

I don't see much of things that could be called 'sanity checks' in
lxc_start, probably i don't understand what do you mean under this term,
but nevermind.

I'm completelly agreed that moving parsing outside of
lxc_start is very good idea - lxc_start could be called via liblxc from
some upper-level application, maybe frontend, and, probably, it would be
nicer to construct lxc_conf directly from some other sources (for example,
from database) then dumping configuration some temporary files, which than
should be passed to lxc_start.

> Thanks for pointing this problem, I feel 0.6.4 will have a very short 
> life period :)

I just hope, that you will have some time to review my patches untill
new code freeze would take it's place ;)




More information about the lxc-devel mailing list