|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>|
|Version:||14||CC:||lpoetter, metherid, mschmidt, notting, plautrba, rvokal|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-09-14 23:46:16 UTC||Type:||---|
|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: 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.