diff options
author | Lennart Poettering <lennart@poettering.net> | 2015-10-31 22:12:51 +0100 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2015-11-12 17:57:04 +0100 |
commit | 79413b673b45adc98dfeaec882bbdda2343cb2f9 (patch) | |
tree | 60306026034427f5016a1da67cdb9d4689e2a5e9 /man/systemd-sysctl.service.xml | |
parent | 485630813db57d8575cf77d6b2966b02df18859b (diff) |
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
Diffstat (limited to 'man/systemd-sysctl.service.xml')
0 files changed, 0 insertions, 0 deletions