In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
This fixes repart's, systemctl's, sysusers' and tmpfiles' specifier
expansion to honour the root dir specified with --root=. This is
relevant for specifiers such as %m, %o, … which are directly sourced
from files on disk.
This doesn't try to be overly smart: specifiers referring to runtime
concepts (i.e. boot ID, architecture, hostname) rather than files on the
medium are left as is. There's certainly a point to be made that they
should fail in case --root= is specified, but I am not entirely convinced
about that, and it's certainly something we can look into later if
there's reason to.
I wondered for a while how to hook this up best, but given that quite a
large number of specifiers resolve to data from files on disks, and most
of our tools needs this, I ultimately decided to make the root dir a
first class parameter to specifier_printf().
Replaces: #16187Fixes: #16183
This moves the definition of the specifier table consisting only of
system and /tmp specifiers into generic code so that we can share it.
This patch only adds one user of it for now. Follow-up patches will add
more.
This is not very pretty, but the code in fs-util.c already provisions for
missing /proc. We ourselves are careful to set up /proc, but not everybody
is and it is important for sysusers to also work where shadow-utils would:
I would like to replace calls to useradd and groupadd in Fedora systemd rpm
scriptlets with a call to sysusers. It has a number of advantages:
- dogfooding
- we don't need to manually duplicate the information from our sysusers
files to scriptlets
- a dependency on shadow-utils is dropped, which transitively drops dependencies
on setup and fedora-repos and bunch of other stuff.
We could try to get 'dnf' and 'rpm --root' and such to be reworked,
but not in any reasonable timeframe. And even if this was done, we'd still
want to support older rpm/dnf versions.
I'm trying to use systemd-sysusers for systemd.rpm itself, and the invocation
in dnf chroot is failing like this:
...
Creating group input with gid 999.
Creating group kvm with gid 36.
Creating group render with gid 998.
Creating group sgx with gid 997.
Creating group systemd-journal with gid 190.
Creating group systemd-network with gid 192.
Creating user systemd-network (systemd Network Management) with uid 192 and gid 192.
Creating group systemd-oom with gid 996.
Creating user systemd-oom (systemd Userspace OOM Killer) with uid 996 and gid 996.
Creating group systemd-resolve with gid 193.
Creating user systemd-resolve (systemd Resolver) with uid 193 and gid 193.
Creating group systemd-timesync with gid 995.
Creating user systemd-timesync (systemd Time Synchronization) with uid 995 and gid 995.
Creating group systemd-coredump with gid 994.
Creating user systemd-coredump (systemd Core Dumper) with uid 994 and gid 994.
Failed to write files: Function not implemented
Let's add more info to make such failures easier to debug.
We usually call specifier_printf() and then check the validity of
the result. In many cases, validity checkers, e.g. path_is_valid(),
refuse too long strings. This makes specifier_printf() refuse such
long results earlier.
Moreover, unit_full_string() and description field in sysuser now
refuse results longer than LONG_LINE_MAX. config_parse() already
refuses the line longer than LONG_LINE_MAX. Hence, it should be ok
to set the same value as the maximum length of the resolved string.
Let's add three defines for the 3 special cases of passwords.
Some of our tools used different values for the "locked"/"invalid" case,
let's settle on using "!*" which means the password is both locked *and*
invalid.
Other tools like to use "!!" for this case, which however is less than
ideal I think, since the this could also be a considered an entry with
an empty password, that can be enabled again by unlocking it twice.
Let's enable this in all tools that intend to write to the OS images.
It's not conditionalized for now, as there already is conditionalization
in the existance or absence of the flag in the GPT partition table (and
it's opt-in), hence it should be OK to just enable this by default for
now if the flag is set.
Let's make use of our own credentials infrastructure in our tools: let's
hook up systemd-sysusers with the credentials logic, so that the root
password can be provisioned this way. This is really useful when working
with stateless systems, in particular nspawn's "--volatile=yes" switch,
as this works now:
# systemd-nspawn -i foo.raw --volatile=yes --set-credential=passwd.plaintext-password:foo
For the first time we have a nice, non-interactive way to provision the
root password for a fully stateless system from the container manager.
Yay!
Previously, the flag did two things at once: enable support for using
generic partitions as root fs if there were only one/allow use of
partition-table-less images as root fs. And secondly, insist that there
was a rootfs, and fail if not. Let's split these two in two separate
options so that they can be used independently of each other.
There are cases where one wants to use one without the other (i.e. when
inspecting things with systemd-dissect tool it should be OK to do so
even if image has no root fs), and it's cleaner anyway.
It's so similar to copy_access(), hence let's move it over and rename it
in similar style to the rest of the functions.
No change in behaviour, just moving things over.
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
In many cases the tables are largely the same, hence define a common set
of macros to generate the common parts.
This adds in a couple of missing specifiers here and there, so is more
thant just refactoring: it actually fixes accidental omissions.
Note that some entries that look like they could be unified under these
macros can't really be unified, since they are slightly different. For
example in the DNSSD service logic we want to use the DNSSD hostname for
%H rather than the unmodified kernel one.
*** Running /home/zbyszek/src/systemd-work/test/test-sysusers/test-14.input (with login.defs symlinked)
login.defs specifies UID allocation range 401–555 that is different than the built-in defaults (201–998)
login.defs specifies GID allocation range 405–666 that is different than the built-in defaults (201–990)
Also, even if login.defs are not present, don't start allocating at 1, but at
SYSTEM_UID_MIN.
Fixes#9769.
The test is adjusted. Actually, it was busted before, because sysusers would
never use SYSTEM_GID_MIN, so if SYSTEM_GID_MIN was different than
SYSTEM_UID_MIN, the tests would fail. On all "normal" systems the two are
equal, so we didn't notice. Since sysusers now always uses the minimum of the
two, we only need to substitute one value.
This basically implements fc58c0c7bf for gshadow.
gpasswd may not have a lock/unlock that behaves the same as passwd, but
according to gshadow(5) the logic of the password field is the same.
As described in #15603, it is a fairly common setup to use a fqdn as the
configured hostname. But it is often convenient to use just the actual
hostname, i.e. until the first dot. This adds support in tmpfiles, sysusers,
and unit files for %l which expands to that.
Fixes#15603.
Let's use "!*" instead of "!!" as invalid password string.
Generally, any invalid password string can be used to for locking an
account, according to shadow(5). To temporarily lock a password of an
account it is commonly implemented to prefix the original password with
a single "!", so that it can later on be unlocked again by removing the
"!", restoring the original password. Thus, the "!" marker is an
indicator for a locked password; the act of prefixing "!" to a
password string is the locking operation; and the removal of a "!"
prefix is the unlock operation. (This is also suggested in shadow(5)).
If we want to entirely lock an account we previously used "!!" as
password string. This is nice since it indicates the password is locked.
However, it is less than ideal, since applying the password unlock
operation once will change the string to "!", which is still a locked
password. Unlocking the password a second time will result in "", i.e.
the empty password, which will in many cases allow logging in without
password. And that's a problem. Hopefully, tools do not allow such
duplicate unlocking, but it's still not a nice property.
By changing our password string to "!*" we get different behaviour: the
password will appear locked. When it is unlocked the password is "*"
which is an invalid password. In that case the password is hence
unlocked but invalid, which is a much better state to be in than the
above.
This is paranoia hardening. Not more. There's no report that anyone
every unlocked an account twice and people could log in.
