Bug 630156

Summary:	variable substitution is inconsistent
Product:	[Fedora] Fedora	Reporter:	Bill Nottingham <notting>
Component:	systemd	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	14	CC:	lpoetter, metherid, mschmidt, notting, plautrba, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-09-14 23:46:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bill Nottingham 2010-09-03 20:28:09 UTC

Description of problem:

Take a file /foo, that defines:
COMMAND=/bin/program

The following is rejected by systemd:
EnvironmentFile=/foo
ExecStart=$COMMAND

The following works:
EnvironmentFile=/foo
ExecStart=/bin/bash -c "exec $COMMAND"

It would be nice to be able to use the simpler version.

Version-Release number of selected component (if applicable):

systemd-9-2

How reproducible:

100%

Comment 1 Lennart Poettering 2010-09-05 23:52:22 UTC

Hmm, we currently do env var substitution only for the command line (i.e. argv[]), not the binary we actually execute (i.e. the first param to execv).

Comment 2 Lennart Poettering 2010-09-06 00:05:06 UTC

Hmm, what concerns me a bit here is that this might be really hard to fix due to the SELinux logic: SELinux requires us to label the listening sockets correctly according to the binary we might eventually run for it. And that means we'd have to do the variable substitution at the time we initialize the socket and not delay it until the time we actually spawn the process. That would be a fairly significant change because it'd require us to calculate the execution env block far in advance, which is really messy since it could change all the time.

Example: somebody changes the default env block for systemd via "systemctl set-environment". This would then have the effect that we might have to relabel some sockets we listen on. And that would be ugly.

This would be certainly doable, however it sounds like a major headache to me. Not only code-wise, but also security-wise.

So, before I burn more brain cells on this: do you have a convincing use case for this?

Comment 3 Bill Nottingham 2010-09-07 17:05:58 UTC

I have a single use case for this. I can work around it, assuming my second command as posted continues to work in future versions.

That said, this restriction should probably be documented (it may be and I just didn't see it.)

Comment 4 Lennart Poettering 2010-09-14 23:46:16 UTC

This behaviour is now documented in git upstream.