In https://bugzilla.redhat.com/show_bug.cgi?id=2156900 sysusers was reporting a
conflict between the following lines:
u root 0:0 "Super User" /root /bin/bash
u root 0 "Super User" /root
The problem is that those configurations are indeed not equivalent. If group 0
exists with a different name, the first line would just create the user, but the
second line would create a 'root' group with a different GID. The second
behaviour seems definitely wrong. (Or at least more confusing in practice than
the first one. The system is in a strange shape, but the second approach takes
an additional step than is worse than doing nothing.)
When this line was initially added, we didn't have the uid:gid functionality for
'u', so we didn't think about this too much. But now we do, so we should use it.
$ build/systemd-sysusers --root=/var/tmp/inst7 --inline 'g foobar 0'
Creating group 'foobar' with GID 0.
$ build/systemd-sysusers --root=/var/tmp/inst7 --inline 'u root 0 "Zuper zuper"'
src/sysusers/sysusers.c:1365: Creating group 'root' with GID 999.
src/sysusers/sysusers.c:1115: Suggested user ID 0 for root already used.
src/sysusers/sysusers.c:1183: Creating user 'root' (Zuper zuper) with UID 999 and GID 999.
vs.
$ build/systemd-sysusers --root=/var/tmp/inst7 --inline 'u root 0:0 "Zuper zuper"'
src/sysusers/sysusers.c:1183: Creating user 'root' (Zuper zuper) with UID 0 and GID 0.
RFC3442 specifies option 121 (Classless Static Routes) that allow a DHCP
server to push arbitrary routes to a client. It has a Local Subnet
Routes section expliciting the behavior of routes with a null (0.0.0.0)
gateway.
Such routes are to be installed on the interface with a Link scope, to
mark them as directly available on the link without any gateway.
Networkd currently drops those routes, which is against the RFC, as
Linux has proper support for such routes.
Fixes: 7f20627 ("network: dhcp4: ignore gateway in static routes if destination is link-local or in the same network")
Linux kernel's bpf-next contains BPF LSM support for s390x. systemd's
test-bpf-lsm currently fails with this kernel.
This is an endianness issue: in the restrict_fs bpf program,
magic_number has type unsigned long (64 bits on s390x), but magic_map
keys are uint32_t (32 bits). Accessing magic_map using 64-bit keys may
work by accident on little-endian systems, but fails hard on big-endian
ones.
Fix by casting magic_number to uint32_t.
Despite popular belief, the default file extracted by GNU tar is not stdin. It
is the value of the TAPE environment variable, falling back on a compile-time
constant. On my system, the default value is /dev/full, which causes tar to
just spin forever due to --ignore-zeros. Always specifying this flag is the
safe thing to do.
~$ tar --show-defaults
--format=gnu -f/dev/full -b20 --quoting-style=escape
--rmt-command=/usr/sbin/grmt
See also: ``(tar)defaults'', available via Info viewers, and in HTML form at:
https://www.gnu.org/s/tar/manual/html_node/defaults.html
We might be running in a chroot as a uid that doesn't exist in /etc/passwd.
Let's make sure we don't fail in this scenario.
We pass $HOME when resetting the env so that we can find a home directory
and skip tests that depend on user name/group.
It's still useful to test the EFI handover logic in systemd-boot.
We use a mkosi.prepare script to install a newer python and update
the system to use it.
When unprivileged mkosi becomes available, builds will be executed
as an unprivileged user, so we won't be able to modify the rootfs
anymore. Let's update the build script to account for this.
When using --private-users, we have to create bind mount points as
the user that will become root in the user namespace, so let's take
that into account.
Also, rename get_battery_identifier() to siphash24_compress_device_sysattr().
This also makes any errors in sd_id128_get_machine() or id128_get_product()
ignored. For the machine ID, the failure should not be significant unless
the file stored in the discharge level is reused by another system, which
is quite unusual. For the product ID, if the firmware provides useless
ID (all zero or all 0xFF), then loading/storing the discharge rate
becomes completely broken, that should be avoided.
Note, now sysattrs are used instead of properties in uevent files, but
both provide the same information, hence no functionality should be
changed.
Before v252, HibernateDelaySec= specifies the maximum timespan that the
system in suspend state, and the system hibernate after the timespan.
However, after 96d662fa4c, the setting is
repurposed as the default interval to measure battery charge level and
estimate the battery discharging late. And if the system has enough
battery capacity, then the system will stay in suspend state and not
hibernate even if the time passed. See issue #25269.
To keep the backward compatibility, let's introduce another setting
SuspendEstimationSec= for controlling the interval to measure
battery charge level, and make HibernateDelaySec= work as of v251.
This also drops implementation details from the man page.
Fixes#25269.
On Arch both delv and dig pull in libnss_resolve:
```
$ grep resolve /etc/nsswitch.conf
hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
```
We also add the necessary deps for ukify to the mkosi configs.
CentOS Stream 8 is dropped from CI because its python version is too
old (3.6) to be able to run ukify.
This adds a tmpfiles.d/ snippet for LoadCredential= style credentials
directories in /etc/ and /run/.
This is done primarily to ensure that the access modes for the dirs are
set up properly, in the most restrictive ways. Specifically these are
set to 0000, so that CAP_DAC_OVERRIDE is necessary to enumerate and read
the credentials, and being UID=0 is not sufficient to do so.
This creates /etc/credstore/, but leaves /run/credstore/ absent if
missing, for now. Thinking is: the latter being non-persistent is
created by software usually, not manually by users, and hence more
likely right. But dunno, we might want to revisit this sooner or later.
This is ultimately an exercise to advertise the LoadCredential= concept
a bit, and do so in a reasonably secure way, underlining the safety of
the concept.
If we don't have CAP_NET_BIND_SERVICE, we won't be able to bind
the stub listener socket, so let's skip creating it and log a warning.
We do the same for the extra stubs if they're configured on privileged
ports.
If we're in a user namespace but not unsharing the network namespace,
we won't be able to bind any privileged ports even with
CAP_NET_BIND_SERVICE, so let's drop it from the retained capabilities
so services can condition themselves on that.
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Tuetuopay
Frantisek Sumsal
Ilya Leoshkevich
Arsen Arsenović
Lennart Poettering
Luca Boccassi
Daan De Meyer
cake03
Jan Janssen
Peter Cai