On Wed, Aug 23, 2006 at 07:04:17PM -0700, Gareth S Bestor wrote: > Pragmatically, I think a simple parser that only handles simple xm config > files would probably be fine 98% of the time, especially if you expect in > most situations the VMs will be created via libvirt anyway. The issue for > us with our old libxm interface was for for our particular product offering > we just didnt have the option to say "also supports most existing xm > configurations" [in terms of official marketing product support statements > it was 'better' to say we dont support any...]. If you are OK with > recommending to users to use libvirt-based tools to create DomUs, but that > most other typical xm config files are supported too (if you put them in > such and such place) then I dont see a problem. Even if people are creating xm config files with non-libvirt tools, or even manually by hand, the likelihood of using the full python expressions is pretty small. For that small set, it would be trivial for an admin to change the config to remove the unsafe python expressions. IMHO, this is a very worthwhile tradeoff between security & features. If the libvirt parsr did detect unsupported python expression, we could trivially propagate the error condition 'UNSAFE_CONFIG_EXPRESSION' to the application to bring it to the user's attention. So in practical terms support would be very good. > At the *very* worst, is there a way you can pipe an arbitrary xm config > file thru xm and have it spit out what it would have done, without actually > doing it? That could be a reliable fallback migration path perhaps. This brings us back to the issue that we don't want to execute arbitrary code to read a config file's data - its just asking for trouble IMHO. It is pretty easy for an admin to convert the config into the sanitised format. Regards, Dan. > On Wed, Aug 23, 2006 at 05:15:26PM -0400, Daniel Veillard wrote: > > On Wed, Aug 23, 2006 at 09:22:08PM +0100, Daniel P. Berrange wrote: > > > Now it would be pretty easy for libvirt to convert the XML file passed > > > into virDefineDomain into a config file for xend & stuf it in /etc/xen > > > The hard part is the reverse - enumerating the config files in the > > > dir & turning them back into XML. I fear we may have to tackle that > > > hard part sooner rather than later so I've been trying to thing of > > > ways we could attack it. Now the key problem is that the xm config > > > files can contain/are in fact python code. > > > > I could see a problem with random apps writing to /etc/ , even if run > > as root that won't fly in general. But well if the goal is compatibility > > with existing xen tools, that may be a sufficient reason. > > Well there's unlikely to be random apps writing into /etc/xen unless > they're related to Xen config. We can ust blacklisted the 'xend-config.sxp' > file (& perhaps the xmexample* files) > > > > * Write a tiny parser for a trivial subset - basically enough to > > > handle the (key, string) pairs & (key, list of string) pairs. > > > Certainly doable - depending on how general purpose we want to > > > get - do we care about the 'if..else' conditional used in the > > > sample /etc/xen/xmexample.vti config file ? We can certainly > > > make a valid case saying we don't care about this because the > > > libvirt XML -> xm config conversion would not generate config > > > using that capability > > > > I'm not too concerned by handling only a subset, this should be data > > and processed as such IMHO. > > Sounds good. > > > > Not a perfect solution, but would satisfy a great deal of common > > > use cases pretty easily without being intrusive into existing code > > > base & pretty secure. > > > > We are basically in agreement :-) > > So I write that parser ? > > Sounds like we should, unless anyone (CIM guys ?) listening in has better > suggestions ? > > Regards, > Dan. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 > -=| > |=- Perl modules: http://search.cpan.org/~danberr/ > -=| > |=- Projects: http://freshmeat.net/~danielpb/ > -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 > -=| > > -- > Libvir-list mailing list > Libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|