Naming is always a matter of preference, and the old name would certainly work,
but I think the new one has the following advantages:
- A verb is better than a noun.
- The name more similar to "the competition", i.e. 'sudo', 'pkexec', 'runas',
'doas', which generally include an action verb.
- The connection between 'systemd-run' and 'run0' is more obvious.
There has been no release yet with the old name, so we can rename without
caring for backwards compatibility.
in uid0/systemd-run/nspawn we already set a window title with a colorful
unicode dot indicating the changed privileges/execution context. This typically
gets overriden by the shell inside the environment however.
Let's tweak this a bit: when we see the window title OSC ANSI sequence
passing through, let's patch in the unicode dot as a prefix to the
title.
This is super pretty, since it makes sure root sessions via 0ad are
really easily recognizable as such, because the window title carries an
🔴 red dot as prefix then.
In interactive terminal mode, let's set a window title that reflects our
change of context to the target. Let's prefix it it with red/yellow
emoji dot in case we changed privileges.
This adds a new --background= switch that allows specifiying a
background color for the terminal while the tool runs.
It also teaches the tool when invoked as uid0 to tint the terminal in a
reddish hue when operating as root, and in a yellowish hue when
operating as any other user.
This should highlight nicely when the user is operating with elevated
privileges, or changed privileges.
This turns "systemd-run" into a multi-call binary. When invoked under
the name "uid0", then it behaves a bit more like traditional "sudo".
This mostly means defaults appropriuate for that, for example a PAM
stack, interactivity and more.
Fixes: #29199
arg_description was either set to arg_unit (i.e. a const char*), or to
char *description, the result of allocation in run(). But description
was decorated with _cleanup_, so it would be freed when going out of the
function. Nothing bad would happen, because the program would exit after
exiting from run(), but this is just all too messy.
Also, strv_join(" ") + shell_escape() is not a good way to escape command
lines. In particular, one the join has happened, we cannot distinguish
empty arguments, or arguments with whitespace, etc. We have a helper
function to do the escaping properly, so let's use that.
Fixup for 2c29813da3.
The command arguments may contain spurious characters, e.g. line-break.
When we use command arguments as a description of a unit, we should
escape them.
Fixes#30187.
Before this we'd fail with a complaint that PIDFDs is not supported by
the service manager. Add some compat support by falling back to classic
numeric PIDs in that case.
The intention was to have this option enabled by default everywhere,
but unfortunately at least one case was found where it breaks
compatibility of a program using systemd-run --scopes and expecting
variables not to be expanded:
https://sources.debian.org/src/pbuilder/0.231/pbuilder-checkparams/#L400
Example run:
systemd-run --quiet --scope --description=pbuilder_build_xfce4-notes-plugin_1.10.0-1.dsc '--slice=system-pbuilder-build-xfce4\x2dnotes\x2dplugin_1.10.0\x2d1-449932.slice' chroot /var/cache/pbuilder/build/449932 dpkg-query -W '--showformat=${Version}' apt
Restore backward compatibility and make the option disabled by default
when --scope is used, and enabled by default for other types.
In case --expand-environment is not specified and a '$' character is
detected, print a warning to nudge users toward specifying the
parameter as needed. In the future we can then flip the default.
Follow-up for 2ed7a221fa
When resolving environment variables we currently silently resolve unset
and invalid environment variables to empty strings. Let's do this
slightly less silently: log about unset and invalid env vars, but still
resolve them to an empty string.
Fixes: #27036
This makes syntax be the same for commands which are started by the manager and
those which are spawned directly (when --scope is used).
Before:
$ systemd-run -q -t echo '$TERM'
xterm-256color
$ systemd-run -q --scope echo '$TERM'
$TERM
Now:
$ systemd-run -q --scope echo '$TERM'
xterm-256color
Previous behaviour can be restored via --expand-environment=no:
$ systemd-run -q --scope --expand-environment=no echo '$TERM'
$TERM
Fixes#22948.
At some level, this is a compat break. Fortunately --scope is not very widely
used, so I think we can get away with this. Having different syntax depending
on whether --scope was used or not was bad UX.
A NEWS entry will be required.
This uses StartExecEx to get the equivalent of ExecStart=:. StartExecEx was
added in b3d593673c, so this will not work with
older systemds.
A hint is emitted if we get an error indicating lack of support. PID1 returns
SD_BUS_ERROR_PROPERTY_READ_ONLY, but I'm checking for
SD_BUS_ERROR_UNKNOWN_PROPERTY too for safety.
Just refactoring, in preparation for future changes.
(Though I think it'd be reasonable to do anyway, those functions were
awfully long.)
'git diff' displays this badly. The middle part of start_transient_service()
is moved to make_transient_service_unit(), and the middle part of
start_transient_trigger() is moved to make_transient_trigger_unit().
start_transient_service() would return two ints: one normally and one via
*retval. We can just return one int and propagate it directly, because we
use DEFINE_MAIN_FUNCTION_WITH_POSITIVE_FAILURE().
Otherwise, if getopt() and friends are used before parse_argv(), then
the GNU extensions may be ignored.
This should not change any behavior at least now, as we usually use
getopt_long() only once per invocation. But in the next commit,
getopt_long() will be used for other arrays, hence this change will
become necessary.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
systemd-run's man page says the following about the working directory of
the process:
"If a command is run as transient scope unit, it will be executed
by systemd-run itself as parent process and will thus inherit the
execution environment of the caller."
This means working directory assignment does not work, as evidenced by
the following invocation:
```bash
$ systemd-run --scope --property=WorkingDirectory=/tmp/ bash -c 'echo $(pwd)'
Unknown assignment: WorkingDirectory=/tmp/
```
However, using the shorthand switch --working-directory silently ignores
this instead of giving a similar error.
```bash
systemd-run --scope --user --working-directory=/tmp/ bash -c 'echo $(pwd)'
Running scope as unit: run-r19cc32e744e64285814dbf2204637a2b.scope
/home/test/projects/systemd
```
This commit fixes this by explicitly generating an error instead of
silently ignoring the switch:
```bash
$ systemd-run --scope --working-directory=/tmp/ bash -c 'echo $(pwd)'
--working-directory is not supported in --scope mode.
```
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Mike Yuan
Antonio Alvarez Feijoo
Yu Watanabe
Matteo Croce
Florian Schmaus
Luca Boccassi
Arthur Shau
Joost Heitbrink
David Tardon
Jan Janssen