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 ( | [email protected] PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
