We should chown what we allocate ourselves, i.e. any pty we allocate
ourselves. But for stuff we propagate, let's avoid that: we shouldn't
make more changes than necessary.
Fixes: #17229
If we set O_NONBLOCK on stdin/stdout directly this means the flag is
left set when we abort abnormally, as we don't get the chance to reset
it again on exit. This might confuse progrms invoking us. Moreover, if
programs invoking us continue to write to the stdout passed to us, they
might be confused by non-blocking mode too.
Hence, let's avoid this if possible: let's reopen stdin/stdout and set
O_NONBLOCK only on the reopend fds, leaving the original fds as they
are.
Prompted-by: https://github.com/systemd/systemd/pull/17070#issuecomment-702304802
*** 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.
We don't (and shouldn't I think) look at them when determining the type of the
user, but they should be used during user/group allocation. (For example, an
admin may specify SYS_UID_MIN==200 to allow statically numbered users that are
shared with other systems in the range 1–199.)
It makes little sense to make the boundary between systemd and user guids
configurable. Nevertheless, a completely fixed compile-time define is not
enough in two scenarios:
- the systemd_uid_max boundary has moved over time. The default used to be
500 for a long time. Systems which are upgraded over time might have users
in the wrong range, but changing existing systems is complicated and
expensive (offline disks, backups, remote systems, read-only media, etc.)
- systems are used in a heterogenous enviornment, where some vendors pick
one value and others another.
So let's make this boundary overridable using /etc/login.defs.
Fixes#3855, #10184.
THis doesn't change the condition's logic at all, but is an attempt to
make things a bit more readable: instead of checking log_target !=
LOG_TARGET_AUTO let's actually list the targets where we want to
consider journal/syslog/kmsg, to make things a bit less confusing. After
all the message here is not to avoid them if LOG_TARGET_AUTO is set, but
to definitely do them in the other cases.
Let's explicitly deactivate all home dirs on shutdown, in order to
properly synchronizing unmounting and avoiding blocking devices.
Previously, we'd rely on automatic deactivation when home directories
become unused. However, that scheme is asynchronous, and ongoing
deactviations might conflicts with attempts to unmount /home. Let's fix
that by providing an explicit service systemd-homed-activate.service
whose only job is to have a ExecStop= line that explicitly deactivates
all home directories on shutdown. This service can the be ordered after
home.mount and similar, ensuring that we'll first deactivate all homes
before deactivating /home itself during shutdown.
This is kept separate from systemd-homed.service so that it is possible
to restart systemd-homed.service without deactivating all home
directories.
Fixes: #16842
If the hostname of a system is set to an fqdn, glibc traditionally
derives a search domain from it if none is explicitly configured.
This is a bit weird, and we currently don't do that in our own search
path logic.
Following #17193 let's turn this behaviour off for now.
Yes, this has a slight chance of pissing people off who think this
behaviour is good. If this is indeed an issue, we can revisit the issue
but in that case if we readd the concept we should do it properly:
derive the search domain from the fqdn in our codebase too and report it
in resolvectl, and in our generated stub files. But I have the suspicion
most people who set the hostname to an fqdn aren#t even aware of this
behaviour nor want it, so let's wait until people complain.
Fixes: #17193
It can be one of "foreign", "missing", "stub", "static", "uplink",
depending on how /etc/resolv.conf is set up:
foreign → someone/something else manages /etc/resolv.conf,
systemd-resolved is just the consumer
missing → /etc/resolv.conf is missing altogether
stub/static/uplink → the file is managed by resolved, with the
well-known modes
Fixes: #17159
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.
This is like membarrier() I guess and basically just exposes CPU
functionality via kernel syscall on some archs. Let's whitelist it for
everyone.
Fixes: #17197
This effectively reverts commit 67acde4869.
After commits 569ad251ad and
67acde4869, -EACCES errors are ignored,
and thus 'udevadm trigger' succeeds even when it is invoked by non-root
users. Moreover, on -EACCES error, log messages are shown in debug
level, so usually we see no message, and users are easily confused
why uevents for devices are not triggered.
It always was the intention to expose this as trusted field _TID=, i.e.
automatically determine it from journald via some SCM_xyz field or so,
but this is never happened, and it's unlikely this will be added anytime
soon to the kernel either, hence let's just generate this sender side,
even if it means it's untrusted.
Let's turn off the search domain logic if a trailing dot is specified
when looking up hostnames and RRs via the Varlink + D-Bus APIs (and thus
also when doing so via nss-resolve). (This doesn't affect lookups via
the stub, since for the any search path logic is done client side
anyway)
It might make sense to force the DNS protocol in this case too (and
disable LLMR + mDNS), but we'll leave that for a different PR — if it
even makes sense. It might also make sense to disable the logic of never
routing single-label lookups to the Internet if a trailing to is
specified, but this needs more discussion too.
Strivtly speaking, this breaks backward compatibility. But setting
too large value into them, then their networking easily breaks.
Note that typically 100 for them is event too large. So, ommiting the
values equal or higher than 1024, and dropping support of k, M, and G
suffixes is OK for normal appropriate use cases.
See discussion in #16643.
Yu Watanabe
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Frantisek Sumsal
Samanta Navarro
Franck Bui
Ronan Pigott
nl6720
Pass Automated Testing Suite