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

[Daniel Lezcano]

Andrian Nord wrote:
> 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 ;)

Right, root is not god :P

>> 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 =)

Yep, right, hopefully the patchset succeed to reach sourceforge soon ...

>> 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 remember but I need a clarification around the word "overriding".

> 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

Ok, this is a good example and illustrates the confusion I have around 
the word "overriding".

The configuration file can define several network (eg. 
lxc-complex.conf), so in your example I can't override 
lxc.network.ipv4=1.2.3.4/24, that is replace a previous lxc.network.ipv4 
option because there may be several and I can't find the right one.

If you mean "adding" by "overriding", and not "replace", I am 100% agree 
to have this approach, much simpler than adding extra config.include in 
the configuration file.

So we have:
  1 - a pre-created container with its configuration can be launched 
with extra configuration options
  2 - a volatile container with a configuration file can be launched 
with extra configuration options
  3 - any volatile containers can be setup via these options without an 
intermediate configuration file

simple and nice.

> 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 =)

Hey ! I like having this kind of funny tricks :)
Maybe it can be improved, but at least we let the user to manage its 
configuration files.

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

ok, let's discuss about that on another thread later.

>> 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.

In our case we want to check conf->rootfs == NULL and command == 
"/sbin/init" but we have just the configuration which is not yet parsed.

> 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.

Absolutely.

>> 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 ;)

I won't consider the config.include as it could be managed from outside 
of lxc.

I am looking the "Add capabilities drop via configuration file" and the 
"Add 'variables' support into config and fstab".

Sorry for taking so much time for reviewing, usually I respond before, 
but I am quite busy right now on some work, so I focus on smaller 
patches like the fixes and small changes.

Thanks
   -- Daniel