Bug 630156

Summary: variable substitution is inconsistent
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: lpoetter, metherid, mschmidt, notting, plautrba, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
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:

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

Take a file /foo, that defines:

The following is rejected by systemd:

The following works:
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):


How reproducible:


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.