Re: Python in Domain Configurations

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Mon, Jul 31, 2023 at 05:59:55AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jul 24, 2023 at 01:28:24PM -0700, Elliott Mitchell wrote:
> > On Fri, Jul 07, 2023 at 03:13:07PM -0700, Elliott Mitchell wrote:
> > > 
> > > The only context I could find was 54fbaf446b and
> > > https://wiki.xenproject.org/wiki/PythonInXlConfig which don't explain
> > > the reasoning.
> > > 
> > > Would the maintainers be amenable to revisiting the decision to remove
> > > support for full Python in domain configuration files?
> > 
> > Any chance of this getting a response?
> > 
> > On examination it appears domain configuration files are a proper subset
> > of Python.  The interface to the parser is a bit interesting, but it
> > looks fairly simple to replace the parser with libpython.
> > 
> > My goal is to create an init script for some automatically started
> > domains.  Issue is there can be ordering concerns with domain start/stop,
> > and this seems best handled by adding an extra setting to the
> > configuration files.  If full Python syntax is available, I can use that
> > for this extra data.

> I don't know full history here, but from my point of view, having a
> full-fledged script as a config file is undesirable for several reasons:
>  - it's easy to have unintended side effects of just loading a config
>    file
>  - loading config file can no longer be assumed to be "cheap"
>  - dynamic config file means you can no long rely on file timestamp/hash
>    to check if anything changed (I don't think it's an issue for the
>    current xl/libxl, but could be for some higher level tools)
>  - leads to issues with various sandboxes - for example SELinux policy
>    allowing scripted config file would be excessively permissive
> 
> So, IMHO reducing config file from a full python (like it used to be in
> xend times) into a static file with well defined syntax was an
> improvement. Lets not go backward.

I wouldn't really call the existing format "well defined".  While there
are patterns which are followed, some of those have rather a lot of
wiggle room.

I'm still looking, but I suspect libpython can be told to only accept
trivial operations (assignments to variables) and reject anything which
includes a jump or conditional.


> As for your original problem, IIUC you would like to add some data that
> would _not_ be interpreted by libxl, right? For that you can use
> comments with some specific marker for your script. This approach used
> to work well for SysV init script, and in fact for a very similar use case
> (ordering and dependencies, among other things).

That is /not/ the issue.  `xl` simply ignores any variables which it
doesn't interpret (this is in fact a Bad Thing).  I need to know what the
limits to the syntax are.

Notice how many init scripts do `. /etc/default/<somefile>` to load
configuration?  I'm thinking it would be very handy to use a similar
technique to load domain.cfg files, with Python being the interpreter.


I also think some portions of the domain.cfg format might work better
with full Python syntax.  For example might it be handier to allow:

disk = [
        {
                'vdev': 'xvda',
                'format': 'raw',
                'access': 'rw',
                'target': '/dev/disk/by-path/foo-bar-baz',
        },
]


It looks pretty feasible to replace the low-level parser with libpython.
Now to examining the "ast" module and finding out whether a file can be
loaded while rejecting conditionals.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445