[systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference

[Luis R. Rodriguez]

On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof at suse.com) wrote:
> 
> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > in particular that of a launcher idea on system to replace alternatives on the
> > ExecStart= line of a systemd service unit file, alternative ideas are of
> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > a little while ago with nothing concrete being recommended but instead a few
> > options being now archived as possibilities. I'm looking for a bit wider
> > review of the approaches and recomendations.
> > 
> > Some general background for non xen folks: old xen requires the launch of
> > a daemon which implements supports of the xenstore, which is the database
> > that xen uses for information about guests / dom0. There are two supported
> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > same thing. Right now old init lets you override which one you pick through
> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > will use the appropriate on there. Systemd doesn't let you use variables on
> > the ExecStart line of a service unit file so alternatives are required.
> > 
> > The reason I'm being very careful here this could set a precedent and at
> > least for the launcher idea it'd require the usage of getenv() and execve(),
> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > have either been merged or suggested before for Linux. The systemd discussion
> > is only specific to Linux but if we have a launcher we could consider it for
> > other supported OSes. All that said I'd like proper review of the security
> > implications of *all* strategies but obviously in particular the launcher
> > idea. I want to tread carefuly before setting precedents.
> 
> You can also just invoke a shell script from ExecStart=. I mean, we try
> to deemphesize them in the boot process, but there's nothing wrong with
> using shell, if you need to parse shell configuraiton fragments and just
> want to execute on ot another program...

I tried this and it didn't work given that systemd expects sd_notify()
to be called from the parent process, in this case the shell script.

Anyway -- time has passed folks and we need to pick something, I really
rather not spend any more time on this series unless a decision is made.
My preference stands as the launcher with getenv() and execve() but I
have also listed all other options available. Please feel free to pick
one but just let me know.

> That said, I'd certainly make a clean cut and drop support for
> /etc/sysconfig from any project I see, earlier rather than later, since
> it's just cruft, a bad idea and should really just go away.

We can use for example something like:

# The RPM way
EnvironmentFile=-/etc/sysconfig/xencommons
# The Debian way
EnvironmentFile=-/etc/default/xencommons
Environment=XENSTORED=oxenstored

And with time this lets us with time get rid of EnvironmentFile.

> But then
> again, I would also just not do the thing with supporting two
> implementations at the same time... 

:)

  Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140605/311ab997/attachment-0001.sig>