Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 04, 2014 at 07:52:56PM -0700, Cameron Norman wrote: > On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez wrote: > > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote: > >> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@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. > > Just use exec before the daemon command. I am pretty certain it can be > just like this: > > ExecStart=/bin/sh -c "exec $XENSTORED" > > xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET > works just fine. Actually this does work on a test unit I just built. I'll proceed with this approach since I haven't heard back from others and I think this is the best approach now. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 04, 2014 at 07:52:56PM -0700, Cameron Norman wrote: On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez mcg...@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 (mcg...@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. Just use exec before the daemon command. I am pretty certain it can be just like this: ExecStart=/bin/sh -c exec $XENSTORED xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET works just fine. Actually this does work on a test unit I just built. I'll proceed with this approach since I haven't heard back from others and I think this is the best approach now. Luis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Thu, Jun 5, 2014 at 12:24 PM, Lennart Poettering wrote: > On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcg...@suse.com) wrote: > >> > 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. > > Hmmm? You shell's "exec" command doesn't actually execve()? What are you > using? This doesn't sound very accurate... $ strace -e execve /bin/sh -c 'exec /bin/echo test' execve("/bin/sh", ["/bin/sh", "-c", "exec /bin/echo test"], [/* 54 vars */]) = 0 execve("/bin/echo", ["/bin/echo", "test"], [/* 54 vars */]) = 0 test +++ exited with 0 +++ I get similar results on Ubuntu using dash. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcg...@suse.com) wrote: > > 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. Hmmm? You shell's "exec" command doesn't actually execve()? What are you using? This doesn't sound very accurate... Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 (mcg...@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 (mcg...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcg...@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 (mcg...@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. Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcg...@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 (mcg...@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. Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 (mcg...@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 (mcg...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcg...@suse.com) wrote: 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. Hmmm? You shell's exec command doesn't actually execve()? What are you using? This doesn't sound very accurate... Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Thu, Jun 5, 2014 at 12:24 PM, Lennart Poettering mzxre...@0pointer.de wrote: On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcg...@suse.com) wrote: 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. Hmmm? You shell's exec command doesn't actually execve()? What are you using? This doesn't sound very accurate... $ strace -e execve /bin/sh -c 'exec /bin/echo test' execve(/bin/sh, [/bin/sh, -c, exec /bin/echo test], [/* 54 vars */]) = 0 execve(/bin/echo, [/bin/echo, test], [/* 54 vars */]) = 0 test +++ exited with 0 +++ I get similar results on Ubuntu using dash. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez wrote: > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote: >> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@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. Just use exec before the daemon command. I am pretty certain it can be just like this: ExecStart=/bin/sh -c "exec $XENSTORED" xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET works just fine. Best, -- Cameron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote: > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@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 pgpAwKG7_foKU.pgp Description: PGP signature
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote: On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@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 pgpAwKG7_foKU.pgp Description: PGP signature
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez mcg...@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 (mcg...@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. Just use exec before the daemon command. I am pretty certain it can be just like this: ExecStart=/bin/sh -c exec $XENSTORED xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET works just fine. Best, -- Cameron -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@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... 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. But then again, I would also just not do the thing with supporting two implementations at the same time... Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@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... 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. But then again, I would also just not do the thing with supporting two implementations at the same time... Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/