Messages in this thread | | | Date | Thu, 5 Jun 2014 20:01:37 +0200 | From | "Luis R. Rodriguez" <> | Subject | Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference |
| |
On Thu, Jun 05, 2014 at 01:22:13PM +0200, Lennart Poettering wrote: > On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcgrof@suse.com) wrote: > > > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote: > > > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@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. > > Hmm? You should "exec" the real daemon binary at the end, not just fork > it off. That wait the shell script process is replaced by the daemon > binary, which is what you want.
I tried both just running it and also running exec foo; both presented the same issue given that shell exec does not really execve.
Luis
| |