Zbigniew Jędrzejewski-Szmek 24536bebe0 core: escape ExecStart command-line received over d-bus
When some transient unit setting is received over D-Bus, we write it it to a
transient unit file. We escape backslashes and specifiers. For most settings
this is enough, because most settings only do parsing and interpolation of
specifiers. When systemd-run is called (or something equivalent that gives us a
command strv), we write ExecStart=, but when reading it, we not only do parsing
and interpolation of specifiers, but also split on semicolons and do variable
substitution. This results in an ugly situation where the commandline is
interpolated twice, once on the caller side, and once in the manager.

I think we need to treat this as a bug: current behaviour seems to be an
accident of implementation and hard to explain in a reasonable way. If we
*were* doing specifier expansion, then it'd be somewhat reasonable so say that
"the commandline is handled the same as ExecStart=". But since we explicitly
prevent specifier expansion, we best we could say is "the commandline has some
subset of features of ExecStart=". I think this is not useful, and unexpected
by users. Since most people use use a shell to call systemd-run, one level of
variable expansion is already done on the caller side, and having to take into
account another level of expansion (with slightly different rules), creates a
big mental overhead when the commandline needs to include a dollar character or
such. Not doing any expansion is much cleaner and easier to explain or use.
Thus I think it's better to change behaviour here, even though in principle
some people could be relying on current behaviour. I think it's more likely
that nobody noticed, because people generally don't use systemd-run for
complicated commandlines.

Thus this commit adds an additional mode of escaping that prevents variable
explansion and other elements of ExecStart= syntax. I looked over all the
places where unit_escape_setting() is called, and I think that only two need to
be changed to use the new flag.

Fixes #23631.
2022-08-24 09:54:48 +02:00
2022-04-26 09:13:57 +00:00
2022-06-01 00:20:30 +09:00
2022-07-02 12:46:16 +02:00
2022-08-02 02:43:38 +09:00
2021-03-30 13:17:58 +02:00
2022-03-09 09:52:41 +00:00
2019-04-12 08:30:31 +02:00
2021-09-30 12:27:06 +02:00
2022-08-23 10:53:47 +02:00
2022-04-06 23:14:21 +09:00
2022-08-23 15:10:15 +02:00

Systemd

System and Service Manager

Count of open issues over time Count of open pull requests over time Semaphore CI 2.0 Build Status
Coverity Scan Status
OSS-Fuzz Status
CIFuzz
CII Best Practices
Language Grade: C/C++
CentOS CI - CentOS 8
CentOS CI - Arch
CentOS CI - Arch (sanitizers)
CentOS CI - Rawhide (SELinux)
Fossies codespell report
Coverage Status
Packaging status

Details

Most documentation is available on systemd's web site.

Assorted, older, general information about systemd can be found in the systemd Wiki.

Information about build requirements is provided in the README file.

Consult our NEWS file for information about what's new in the most recent systemd versions.

Please see the Code Map for information about this repository's layout and content.

Please see the Hacking guide for information on how to hack on systemd and test your modifications.

Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.

When preparing patches for systemd, please follow our Coding Style Guidelines.

If you are looking for support, please contact our mailing list or join our IRC channel.

Stable branches with backported patches are available in the stable repo.

S
Description
systemd patched fork
Readme
409 MiB
Languages
C 88.5%
Shell 5.7%
Python 4.6%
Meson 1.1%