From a report in https://bugzilla.redhat.com/show_bug.cgi?id=1861463:
usb-gadget.target: Failed to load configuration: No such file or directory
usb-gadget.target: Failed to load configuration: No such file or directory
usb-gadget.target: Trying to enqueue job usb-gadget.target/start/fail
usb-gadget.target: Failed to load configuration: No such file or directory
Assertion '!bus_error_is_dirty(e)' failed at src/libsystemd/sd-bus/bus-error.c:239, function bus_error_setfv(). Ignoring.
sys-devices-platform-soc-2100000.bus-2184000.usb-ci_hdrc.0-udc-ci_hdrc.0.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit usb-gadget.target not found.
I *think* this is the place where the reuse occurs: we call
bus_unit_validate_load_state(unit, e) twice in a row.
This allows more granular access control in PolicyKit rules, similar to
/etc/sudoers, for polkit actions:
* org.freedesktop.machine1.host-shell
* org.freedesktop.machine1.shell
Example configuration, place in /etc/polkit-1/rules.d/
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.machine1.host-shell"
&& subject.user == "my-user"
&& action.lookup("user") == "target-user") {
return polkit.Result.YES;
}
});
I happen to have a machine where /boot is not a separate mountpoint,
but rather just a directory under /. After upgrade to recent Fedora,
I found out that grub2 can't find any new kernels.
This happens because loadentry script generates kernel and initrd file
paths relative to /boot, while grub2 expects path to be relative to the
root of filesystem on which they are residing.
This commit fixes this issue by using stat's %m to find the mount point
of a partition holding the images, and using it as a prefix to be
removed from ENTRY_DIR_ABS.
Note that %m for stat requires coreutils 8.6, released in Oct 2010.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Apparently, if IO is still in flight at the moment we invoke LOOP_CLR_FD
it is likely simply dropped (probably because yanking physical storage,
such as a USB stick would drop it too). Let's protect ourselves against
that and always sync explicitly before we invoke it.
Fixed below systemd codesonar warning.
isprint() is invoked here with an argument of signed
type char, but only has defined behavior for int arguments that are
either representable as unsigned char or equal to the value
of macro EOF(-1).
As per codesonar report, in a number of libc implementations, isprint()
function implemented using lookup tables (arrays): passing in a
negative value can result in a read underrun.
The explicit limit is dropped, which means that we return to the kernel default
of 50% of RAM. See 362a55fc14 for a discussion why that is not as much as it
seems. It turns out various applications need more space in /dev/shm and we
would break them by imposing a low limit.
While at it, rename the define and use a single macro for various tmpfs mounts.
We don't really care what the purpose of the given tmpfs is, so it seems
reasonable to use a single macro.
This effectively reverts part of 7d85383edb. Fixes#16617.
The new retry intervals are [15, 20, 26, 34, 45, 60, 80, 106, 141, 188, 250,
333, 360, ...]. This should allow graceful response if a transient network
failure is encountered. Growth is exponential, but with a small power and
capped to a non-too-large value so that we resynchronize within a few minutes
after network is restored. I made the minimum 15 s to make sure that we never
send packets more often than that.
Fixes#16492.
Allows to specify mount options for RootImage.
In case of multi-partition images, the partition number can be prefixed
followed by colon. Eg:
RootImageOptions=1:ro,dev 2:nosuid nodev
In absence of a partition number, 0 is assumed.
This should be enough to fix https://bugzilla.redhat.com/show_bug.cgi?id=1856514.
But the limit should be significantly higher than 10% anyway. By setting a
limit on /tmp at 10% we'll break many reasonable use cases, even though the
machine would deal fine with a much larger fraction devoted to /tmp.
(In the first version of this patch I made it 25% with the comment that
"Even 25% might be too low.". The kernel default is 50%, and we have been using
that seemingly without trouble since https://fedoraproject.org/wiki/Features/tmp-on-tmpfs.
So let's just make it 50% again.)
See 7d85383edb.
(Another consideration is that we learned from from the whole initiative with
zram in Fedora that a reasonable size for zram is 0.5-1.5 of RAM, and that pretty
much all systems benefit from having zram or zswap enabled. Thus it is reasonable
to assume that it'll become widely used. Taking the usual compression effectiveness
of 0.2 into account, machines have effective memory available of between
1.0 - 0.2*0.5 + 0.5 = 1.4 (for zram sized to 0.5 of RAM) and
1.0 - 0.2*1.5 + 1.5 = 2.2 (for zram 1.5 sized to 1.5 of RAM) times RAM size.
This means that the 10% was really like 7-4% of effective memory.)
A comment is added to mount-util.h to clarify that tmp.mount is separate.
Previously, on DHCPv4 address renewal, the old address may be removed
while the new address is not ready yet.
This also simplifies the logic of removing address and routes.
When we're disabling controller on a direct child of root cgroup, we
forgot to add root slice into cgroup realization queue, which prevented
proper disabling of the controller (on unified hierarchy).
The mechanism relying on "bounce from bottom and propagate up" in
unit_create_cgroup doesn't work on unified hierarchy (leaves needn't be
enabled). Drop it as we rely on the ancestors to be queued -- that's now
intentional but was artifact of combining the two patches:
cb5e3bc37d ("cgroup: Don't explicitly check for member in UNIT_BEFORE") v240~78
65f6b6bdcb ("core: fix re-realization of cgroup siblings") v245-rc1~153^2
Fixes: #14917
The current implementation is LIFO, which is a) confusing b) prevents
some ordered operations on the cgroup tree (e.g. removing children
before parents).
Fix it quickly. Current list implementation turns this from O(1) to O(n)
operation. Rework the lists later.
We frequently want to set a timer relative to the current time. Let's
add an explicit API for this. This not only saves us a few lines of code
everywhere and simplifies things, but also allows us to do correct
overflow checking.
The tests fail in Fedora's koji with a timeout. Let's just bump
the timeout:
--- stderr ---
Failed to connect to system bus: No such file or directory
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-exists.service: Failed to create cgroup /system.slice/kojid.service/path-exists.service: Permission denied
path-exists.service: Succeeded.
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-exists.service: Failed to create cgroup /system.slice/kojid.service/path-exists.service: Permission denied
path-exists.service: Succeeded.
path-exists.path: Succeeded.
Failed to connect to system bus: No such file or directory
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-existsglob.service: Failed to create cgroup /system.slice/kojid.service/path-existsglob.service: Permission denied
path-existsglob.service: Succeeded.
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-existsglob.service: Failed to create cgroup /system.slice/kojid.service/path-existsglob.service: Permission denied
path-existsglob.service: Succeeded.
path-existsglob.path: Succeeded.
Failed to connect to system bus: No such file or directory
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-changed.service: Failed to create cgroup /system.slice/kojid.service/path-changed.service: Permission denied
path-changed.service: Succeeded.
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-changed.service: Failed to create cgroup /system.slice/kojid.service/path-changed.service: Permission denied
path-changed.service: Succeeded.
path-changed.path: Succeeded.
Failed to connect to system bus: No such file or directory
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-modified.service: Failed to create cgroup /system.slice/kojid.service/path-modified.service: Permission denied
path-modified.service: Succeeded.
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-modified.service: Failed to create cgroup /system.slice/kojid.service/path-modified.service: Permission denied
path-modified.service: Succeeded.
path-modified.path: Succeeded.
Failed to connect to system bus: No such file or directory
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-mycustomunit.service: Failed to create cgroup /system.slice/kojid.service/path-mycustomunit.service: Permission denied
path-mycustomunit.service: Succeeded.
path-unit.path: Succeeded.
Failed to connect to system bus: No such file or directory
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-directorynotempty.service: Failed to create cgroup /system.slice/kojid.service/path-directorynotempty.service: Permission denied
path-directorynotempty.service: Succeeded.
-.slice: Failed to enable/disable controllers on cgroup /system.slice/kojid.service, ignoring: Permission denied
path-directorynotempty.service: Failed to create cgroup /system.slice/kojid.service/path-directorynotempty.service: Permission denied
path-directorynotempty.service: Failed to attach to cgroup /system.slice/kojid.service/path-directorynotempty.service: No such file or directory
path-directorynotempty.service: Failed at step CGROUP spawning /bin/true: No such file or directory
path-directorynotempty.service: Main process exited, code=exited, status=219/CGROUP
path-directorynotempty.service: Failed with result 'exit-code'.
Test timeout when testing path-directorynotempty.path
When a prefix is delegated to an interface that is already sending
RAs, send an RA immediately to inform clients of the new prefix.
This allows them to start using it immediately instead of waiting
up to nearly 10 minutes (depending on when the last timed RA was
sent). This type of situation might occur if, for example, an
outage of the WAN connection caused the addresses and prefixes to
be lost and later regained after service was restored. The
condition for the number of RAs sent being above 0 simultaneously
ensures that RADV is already running and that this code doesn't
send any RAs before the timed RAs have started when the interface
first comes up.
Previously, we assumed that success meant we definitely got a valid
pointer. There is at least one edge case where this is not true (i.e.,
we can get both a 0 return value, and *also* a NULL pointer):
4246bb550d/libselinux/src/procattr.c (L175)
When this case occurrs, if we don't check the pointer we SIGSEGV in
early initialization.
Let's find the right os-release file on the host side, and only mount
the one that matters, i.e. /etc/os-release if it exists and
/usr/lib/os-release otherwise. Use the fixed path /run/host/os-release
for that.
Let's also mount /run/host as a bind mount on itself before we set up
/run/host, and let's mount it MS_RDONLY after we are done, so that it
remains immutable as a whole.
It needs to be world readable (unlike /etc/shadow) when created anew.
This fixes systems that boot with "systemd-nspawn --volatile=yes", i.e.
come up with an entirely empty /etc/ and thus no existing /etc/passwd
file when firstboot runs.
We want our OS trees to be MS_SHARED by default, so that our service
namespacing logic can work correctly. Thus in nspawn we mount everything
MS_SHARED when organizing our tree. We do this early on, before changing
the user namespace (if that's requested). However CLONE_NEWUSER actually
resets MS_SHARED to MS_SLAVE for all mounts (so that less privileged
environments can't affect the more privileged ones). Hence, when
invoking it we have to reset things to MS_SHARED afterwards again. This
won't reestablish propagation, but it will make sure we get a new set of
mount peer groups everywhere that then are honoured for the mount
namespaces/propagated mounts set up inside the container further down.
This API is a complete mess. We forgot to do a hashed comparison for duplicate
entries and we use a direct pointer comparison. For trivial_hash_ops the result
is the same. For all other case, it's not. Fixing this properly will require
auditing all the uses of set_put() and ordered_set_put(). For now, let's just
acknowledge the breakage.
We would add and remove definitions based on which colors were used by other
code. Let's just define all of them to simplify tests and allow easy comparisons
which colors look good.
There are a lot of edge cases that the current implementation
doesn't handle, especially in cases where one of passwd/shadow
exists and the other doesn't exist. For example, if
--root-password is specified, we will write /etc/shadow but
won't add a root entry to /etc/passwd if there is none.
To fix some of these issues, we constrain systemd-firstboot to
only modify /etc/passwd and /etc/shadow if both do not exist
already (or --force) is specified. On top of that, we calculate
all necessary information for both passwd and shadow upfront so
we can take it all into account when writing the actual files.
If no root password options are given --force is specified or both
files do not exist, we lock the root account for security purposes.
Fixes#16401.
c80a9a33d0 introduced the .can_fail field,
but didn't set it on .targets. Targets can fail through dependencies.
This leaves .slice and .device units as the types that cannot fail.
$ systemctl cat bad.service bad.target bad-fallback.service
[Service]
Type=oneshot
ExecStart=false
[Unit]
OnFailure=bad-fallback.service
[Service]
Type=oneshot
ExecStart=echo Fixing everythign!
$ sudo systemctl start bad.target
systemd[1]: Starting bad.service...
systemd[1]: bad.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: bad.service: Failed with result 'exit-code'.
systemd[1]: Failed to start bad.service.
systemd[1]: Dependency failed for bad.target.
systemd[1]: bad.target: Job bad.target/start failed with result 'dependency'.
systemd[1]: bad.target: Triggering OnFailure= dependencies.
systemd[1]: Starting bad-fallback.service...
echo[46901]: Fixing everythign!
systemd[1]: bad-fallback.service: Succeeded.
systemd[1]: Finished bad-fallback.service.
The Address objects in the set generated by ndisc_router_generate_addresses()
have the equivalent prefixlen, flags, prefered lifetime.
This commit makes ndisc_router_generate_addresses() return Set of
in6_addr.
The CI occasionally fail in test-path with a timeout. test-path loads
units from the filesystem, and this conceivably might take more than
the default limit of 3 s. Increase the timeout substantially to see if
this helps.
Opening a verity device is an expensive operation. The kernelspace operations
are mostly sequential with a global lock held regardless of which device
is being opened. In userspace jumps in and out of multiple libraries are
required. When signatures are used, there's the additional cryptographic
checks.
We know when two devices are identical: they have the same root hash.
If libcrypsetup returns EEXIST, double check that the hashes are really
the same, and that either both or none have a signature, and if everything
matches simply remount the already open device. The kernel will do
reference counting for us.
In order to quickly and reliably discover if a device is already open,
change the node naming scheme from '/dev/mapper/major:minor-verity' to
'/dev/mapper/$roothash-verity'.
Unfortunately libdevmapper is not 100% reliable, so in some case it
will say that the device already exists and it is active, but in
reality it is not usable. Fallback to an individually-activated
unique device name in those cases for robustness.
../src/home/homectl-pkcs11.c:19:13: warning: ‘pkcs11_callback_data_release’ defined but not used [-Wunused-function]
19 | static void pkcs11_callback_data_release(struct pkcs11_callback_data *data) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
decompress_blob_zstd() would allocate ever bigger buffers in a loop trying to
get a buffer big enough to decompress the input data. This is wasteful, since
we can just query the size of the decompressed data from the compressed header.
Worse, it doesn't work when the output size is capped, i.e. when dst_max != 0.
If the decompressed blob happened to be bigger than dst_max, decompression
would fail with -ENOBUFS. We need to use "stream decompression" instead, and
only get min(uncompressed size, dst_max) bytes of output.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1856037 in a second way.
SD_JOURNAL_FOREACH_DATA() and SD_JOURNAL_FOREACH_UNIQUE() would immediately
terminate when a field couldn't be accessed. This can happen for example when a
field is compressed with an unavailable compression format. But it's likely
that this is the wrong thing to do: the caller for example might want to
iterate over the fields but isn't interested in all of them. coredumpctl is
like this: it uses SD_JOURNAL_FOREACH_DATA() but only uses a subset of the
fields.
Add two new functions sd_journal_enumerate_good_data() and
sd_journal_enumerate_good_unique() that retry sd_journal_enumerate_data() and
sd_journal_enumerate_unique() if the return value is something that applies to
a single field: ENOBUS, E2BIG, EOPNOTSUPP.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1856037.
An alternative would be to make the macros themselves smarter instead of adding
new symbols, and do the looping internally in the macro. I don't like that
approach for two reasons. First, it would embed the logic in the macro, so
recompilation would be required if we decide to update the logic. With the
current version of the patch, recompilation is required to use the new symbols,
but after that, library upgrades are enough. So the current approach is safer
in case further updates are needed. Second, our headers use primitive C, and it
is hard to do the macros without using newer features.
Let's split this out into its own helper function we can reuse at
various places.
Also, let's avoid signed values where we can so that we can cover more
of the available time range.
Let's use the new flag wherever we read key material/passphrases/hashes
off disk, so that people can plug in their own IPC service as backend if
they like, easily.
(My main goal was actually to support this for crypttab key files — i.e.
that you can specify AF_UNIX sockets as third column in crypttab — but
that's harder to implement, since the keys are read via libcryptsetup's
API, not ours.)
According to the docs, and to the
org.freedesktop.login1.get-reboot-to-boot-loader-menu code, the
(oneshot) boot-loader-menu timeout should be stored in
/run/systemd/reboot-to-boot-loader-menu, but the set method was storing it
in /run/systemd/reboot-to-loader-menu.
This commit fixes this. Note that the fixed name also is a better match
for the dbus call names and matches the related
/run/systemd/reboot-to-boot-loader-entry structure, so fixing the set code,
rather then the get code + docs seems like the right thing to do here.
In NetworkdBridgeTests.test_bridge_configure_without_carrier of
systemd-networkd-tests.py
```
bridge99: MAC address: 2e:3a:ec:4d:d3:62
Assertion 'sd_ipv4ll_is_running(ll) == 0' failed at src/libsystemd-network/sd-ipv4ll.c:110, function int sd_ipv4ll_set_mac(sd_ipv4ll *, const struct ether_addr *)(). Ignoring.
bridge99: Could not update MAC address in IPv4LL client: Device or resource busy
```
Since commit 883eb9be98, vconsole-setup might be
called again to operate on dummy console where font operations are not
supported but where it's still important to have the correct keymap set [0][1].
vconsole-setup is mainly called by udev but can also be run via a dependency of
an early service. Both cases might end up calling vconsole-setup on the dummy
console.
The first case can happen during early boot even on systems that use (instead
of the dummy console) a "simple" video console driver supporting font
operations (such as vgacon) until a more specific driver (such as i915) takes
the console over. While this is happening vgacon is deactivated and temporarly
replaced by the dummy console [2].
There are also other cases where systemd-vconsole-setup might be called on
dummy console especially during (very) early boot. Indeed
systemd-vconsole-setup.service might be pulled in by early interactive services
such as 'dracut-cmdline-ask.service` which is run before udev.
If that happens on platforms with no grapical HWs (such as embedded ARM) or
with dummy console initially installed until a driver takes over (like Xen and
xen-fbfront) then setting font will fail.
Therefore this patch downgrades the log message emitted when setting font fails
to LOG_DEBUG and when font operations is not implemented like it's the case for
the dummy console.
Fixes: #16406.
[0] https://github.com/systemd/systemd/issues/10826
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1652473
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/vga/vgaarb.c?h=v5.7#n204
When sd_netlink_call_async() timed out, then we reply the synthetic
error message, but it was not sealed. So, reading the message causes
the following assertion:
```
Assertion 'm->sealed' failed at src/libsystemd/sd-netlink/netlink-message.c:652, function netlink_message_read_internal(). Ignoring.
```
sd_netlink_message_set_flags is called without NLM_F_ACK which results in
a timeout while networkd is waiting for an ACK that the kernel will never send.
This changes the code to allow looking at multiple files with different
prefixes, but uses "/etc" and "/usr/lib". rpm-ostree uses
/usr/lib/{passwd,group} with nss-altfiles. I see no harm in simply trying both
paths on all systems.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1857530.
A minor memory leak is fixed: hashmap_put() returns -EEXIST is the key is
present *and* and the value is different. It return 0 if the value is the
same. Thus, we would leak the user/group name if it was specified multiple
times with the same uid/gid. I opted to remove the warning message completely:
with multiple files it is reasonable to have the same name defined more than
once. But even with one file the warning is dubious: all tools that read those
files deal correctly with duplicate entries and we are not writing a linter.
The test binary has two modes: in the default argument-less mode, it
just checks that "root" can be resolved. When invoked manually, a root
prefix and user/group names can be specified.
When renaming a network interface, the new name may be used as an
alternative name. In that case, let's swap the current name and the
alternative name. That is, first drop the new name from the list of
alternative names, then rename the interface, finally set the old name
as an alternative name.
We use LOG_PRI() in all log_*() functions, so let's do that here too for
consistency. Effectively this doesn't change anything since we only use
LOG_{INFO,DEBUG,...} as the argument.
When the kernel does not provide a modalias, we generate our own for usb devices.
For some reason, we generated the expected usb:vXXXXpYYYY string, suffixed by "*".
It was added that way already in 796b06c21b, but I
think that was a mistake, and Kay was thinking about the match pattern instead
of the matched string.
For example, for a qemu device:
old: "usb:v0627p0001*"
new: "usb:v0627p0001:QEMU USB Tablet"
On the match side, all hwdb files in the wild seem to be using match patterns
with "*" at the end. So we can add more stuff to our generated modalias with
impunity.
This will allow more obvious and more certain matches on USB devices. In
principle the vendor+product id should be unique, but it's only 8 digits, and
there's a high chance of people getting this wrong. And matching the wrong
device would be quite problematic. By including the name in the match string we
make a mismatch much less likely.
E.g. udevadm test prints "Invalid inotify descriptor." which is
meaningless without any context. I think it should be OK to call udev_watch_end()
from a cleanup path without any warning (even at debug level).
There is no reason to consider this wrong. In fact one could argue that +=
is more appropriate, because we always add to options, and not replace previous
assignments. If we output a debug message, we implicitly ask people to "fix" this,
and we shouldn't.
Also, all our rules use += right now.
The kernel interface requires setting up read-only bind-mounts in
two steps, the bind first and then a read-only remount.
Fix nspawn-mount, and cover this case in the integration test.
Fixes#16484
If DHCP4 client lost a lease, and then soon acquire new lease, then
the removal of the old address may not be completed. If that happens,
and the new and old addresses are the same, then the new address will be
considered as a foreign address. Such a situation can occur when the
DHCP4 server is restarted.
This makes networkd wait for the removal of the old address when a new
lease is acquired.
This also makes the link in configuring state when renewing address.
When DHCP6 and RA are enabled, and RA does not provide any addresses,
then link may become configured state even if no address is assigned,
due to the time-lag between RA completion and DHCP reply.
This makes if DHCP is explicitly enabled, then link must have at least
one valid address to be in the configured state.
let's separate things out a bit, to make it easier to discern log output
and catalog data.
catalog data is now colored green (which is a color we don't use for log
data currently), and prefixed with a block shade.
When the RTC time at boot is off in the future by a few days, OnCalendar=
timers will be scheduled based on the time at boot. But if the time has been
adjusted since boot, the timers will end up scheduled way in the future, which
may cause them not to fire as shortly or often as expected.
Update the logic so that the time will be adjusted based on monotonic time.
We do that by calculating the adjusted manager startup realtime from the
monotonic time stored at that time, by comparing that time with the realtime
and monotonic time of the current time.
Added a test case to validate this works as expected. The test case creates a
QEMU virtual machine with the clock 3 days in the future. Then we adjust the
clock back 3 days, and test creating a timer with an OnCalendar= for every 15
minutes. We also check the manager startup timestamp from both `systemd-analyze
dump` and from D-Bus.
Test output without the corresponding code changes that fix the issue:
Timer elapse outside of the expected 20 minute window.
next_elapsed=1594686119
now=1594426921
time_delta=259198
With the code changes in, the test passes as expected.
The test is failing in koji, and the line from printf() does not end up
in the logs for some reason. log_info() works fine, so let's just use
that here too.
Read-only /var/tmp is more likely, because it's backed by a real device. /tmp
is (by default) backed by tmpfs, but it doesn't have to be. In both cases the
same consideration applies.
If we boot with read-only /var/tmp, any unit with PrivateTmp=yes would fail
because we cannot create the subdir under /var/tmp to mount the private directory.
But many services actually don't require /var/tmp (either because they only use
it occasionally, or because they only use /tmp, or even because they don't use the
temporary directories at all, and PrivateTmp=yes is used to isolate them from
the rest of the system).
To handle both cases let's create a read-only directory under /run/systemd and
mount it as the private /tmp or /var/tmp. (Read-only to not fool the service into
dumping too much data in /run.)
$ sudo systemd-run -t -p PrivateTmp=yes bash
Running as unit: run-u14.service
Press ^] three times within 1s to disconnect TTY.
[root@workstation /]# ls -l /tmp/
total 0
[root@workstation /]# ls -l /var/tmp/
total 0
[root@workstation /]# touch /tmp/f
[root@workstation /]# touch /var/tmp/f
touch: cannot touch '/var/tmp/f': Read-only file system
This commit has more changes than I like to put in one commit, but it's touching all
the same paths so it's hard to split.
exec_runtime_make() was using the wrong cleanup function, so the directory would be
left behind on error.
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
Let's move the heavy lifting out of the bus call implemntations, and
into generic code.
This allows us to expose them easily via Varlink too in a later commit.
sssd people don't like enumeration and for some other cases it's not
nice to support either, in particular when synthesizing records for
container/userns UID/GID ranges.
Hence, let's make enumeration optional.
Let's add a catalog entry explaining further details.
Most importantly though: talk to PID 1 directly, via the private D-Bus
socket, so that this actually works correctly during early boot, where
D-Bus is not around.
The test would always fail with a long uname. In F33 this is right
now "5.8.0-0.rc2.20200622git625d3449788f.1.fc33.x86_64" which caused the
test to always fail.
Commit b0ca726585 "rpm: avoid hiding errors from systemd commands" remove hiding errors and output
for other macros, but did not do that for %sysusers_create_package and %tmpfiles_create_package.
This change syncs their behaviour with %sysusers_create and %tmpfiles_create
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
The last line in this macros was actually "SYSTEMD_INLINE_EOF " with a space at the end,
but the shell was instructed to look for a line without space.
Macros %sysusers_create_inline and %tmpfiles_create_inline did not have this mistake.
An example:
[root@rosa-2019 bind-server]# cat /etc/passwd | grep named
[root@rosa-2019 bind-server]# cat /tmp/bs
systemd-sysusers --replace=/usr/lib/sysusers.d/named.conf - <<SYSTEMD_INLINE_EOF >/dev/null 2>&1 || :
u named - "BIND DNS Server" /var/lib/named
g named - -
m named named
SYSTEMD_INLINE_EOF
[root@rosa-2019 bind-server]# sh /tmp/bs
/tmp/bs: line 5: warning: here-document at line 1 delimited by end-of-file (wanted `SYSTEMD_INLINE_EOF')
[root@rosa-2019 bind-server]# bash /tmp/bs
/tmp/bs: line 5: warning: here-document at line 1 delimited by end-of-file (wanted `SYSTEMD_INLINE_EOF')
[root@rosa-2019 bind-server]# bash --version
GNU bash, version 5.0.17(1)-release (x86_64-openmandriva-linux-gnu)
The user and group named were NOT created!
Now I remove the trailing space after "SYSTEMD_INLINE_EOF" and rerun:
[root@rosa-2019 bind-server]# sh /tmp/bs
[root@rosa-2019 bind-server]# tail -n 1 /etc/group
named❌485:named
[root@rosa-2019 bind-server]#
The user and group have been created correctly.
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>