Bug 630156 - variable substitution is inconsistent
Summary: variable substitution is inconsistent
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-09-03 20:28 UTC by Bill Nottingham
Modified: 2014-03-17 03:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-09-14 23:46:16 UTC
Type: ---

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.