People do have usernames with dots, and it makes them very unhappy that systemd
doesn't like their that. It seems that there is no actual problem with allowing
dots in the username. In particular chown declares ":" as the official
separator, and internally in systemd we never rely on "." as the seperator
between user and group (nor do we call chown directly). Using dots in the name
is probably not a very good idea, but we don't need to care. Debian tools
(adduser) do not allow users with dots to be created.
This patch allows *existing* names with dots to be used in User, Group,
SupplementaryGroups, SocketUser, SocketGroup fields, both in unit files and on
the command line. DynamicUsers and sysusers still follow the strict policy.
user@.service and tmpfiles already allowed arbitrary user names, and this
remains unchanged.
Fixes#12754.
New functions are called valid_user_group_name_compat() and
valid_user_group_name_or_id_compat() and accept dots in the user
or group name. No functional change except the tests.
If networkctl crashes, like recently with SIGABRT, it returns absolutely
no output, which may be confusing during debugging. Help it a little
with a short informative message.
Don't claim we'd use cgroup.deny much. It's just a way to remove stuff
from device lists, which is nothing we allow users to explicitly
configure.
Also, extend documentation when wildcards may be used, and when not.
This particular test case keeps intermittently failing due to crashing
LSan when running under clang+ASan. Generally, sanitizers don't
like seccomp filters, so the best option here is to just switch this
test off for this scenario.
`adduser` is in certain cases a standalone package which provides a
better user experience. In other cases it's just a symlink to `useradd`.
And some distributions don't have `adduser` at all, like Arch Linux.
Let's use the `useradd` binary instead, which should provide the same
functionality everywhere.
v2:
- do not watch mtime of transient and generated dirs
We'd reload the map after every transient unit we created, which we don't
need to do, since we create those units ourselves and know their fragment
path.
This reworks how we load units from disk. Instead of chasing symlinks every
time we are asked to load a unit by name, we slurp all symlinks from disk
and build two hashmaps:
1. from unit name to either alias target, or fragment on disk
(if an alias, we put just the target name in the hashmap, if a fragment
we put an absolute path, so we can distinguish both).
2. from a unit name to all aliases
Reading all this data can be pretty costly (40 ms) on my machine, so we keep it
around for reuse.
The advantage is that we can reliably know what all the aliases of a given unit
are. This means we can reliably load dropins under all names. This fixes#11972.
It turns out most possible symlinks are invalid, because the type has to match,
and template units can only be linked to template units.
I'm not sure if the existing code made the same checks consistently. At least
I don't see the same rules expressed in a single place.
I adjusted the tests to pass. I don't think the behaviour makes much sense,
even if we ignore the issue with "lazy loading" of aliases. E.g. in the
last section, the fact that dropins for yup@.service and yup@3.service are
not loaded seems to be a plain old bug.
waitid(2) and the libc function signature calls this "exit status", and
uses "exit code" for something different. Let's stick to the same
nomenclature hence.
