By default, label_ops is initialized with a NULL pointer which translates
to noop labelling operations. In mac_selinux_init() and the new mac_smack_init(),
we initialize label_ops with a MAC specific LabelOps pointer.
We also introduce mac_init() to initialize any configured MACs and replace all
usages of mac_selinux_init() with mac_init().
When closing the FILE handle attached to a memstream, it may attempt to
do a realloc() that may fail during OOM situations, in which case we are
left with the buffer pointer pointing to NULL and buffer size > 0. For
example:
```
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
void *realloc(void *ptr, size_t size) {
return NULL;
}
int main(int argc, char *argv[])
{
FILE *f;
char *buf;
size_t sz = 0;
f = open_memstream(&buf, &sz);
if (!f)
return -ENOMEM;
fputs("Hello", f);
fflush(f);
printf("buf: 0x%lx, sz: %lu, errno: %d\n",
(unsigned long) buf, sz, errno);
fclose(f);
printf("buf: 0x%lx, sz: %lu, errno: %d\n",
(unsigned long) buf, sz, errno);
return 0;
}
```
```
$ gcc -o main main.c
$ ./main
buf: 0x74d4a0, sz: 5, errno: 0
buf: 0x0, sz: 5, errno: 0
```
This might do unexpected things if the underlying code expects a valid
pointer to the memstream buffer after closing the handle.
Found by Nallocfuzz.
Notifications from /proc/self/mountinfo are async, so if we stop a
service (and while doing so get rid of the credentials mount point of
it), then it will take a while until the notification reaches us and we
actually scan the table again. In particular as we nowadays ratelimit
notifications on the table, since it's so inefficient. And as I learnt
the ratelimiting is actually quite regularly hit during shutdown, where
a flurry of umount events are genreated. Hence, let's check if a mount
point is actually a mountpoint before trying to unmount it. And if it
isn't let's wait for the notification to come in.
(This race might be triggred not just by us on ourselves btw: there are
other daemons that unmount stuff when stopping where the race also
exists, but might simply be harder to trigger: if during service
shutdown these services remove some mount then they might collide with
us doing the same. After all, we have the rule to unmount everything
mounted automatically for you during shutdown.)
In the long run we should also start making us of this when it becomes
available: https://github.com/util-linux/util-linux/issues/2132 With
that we can make issues like this go away entirely from our side of
things at least.
Fixes: #25527
Follow-up for: #27734
It makes sense to propagate the select log level we maintain also into
glibc, so that any code that uses syslog() directly that ends up in our
processes (libraries and such) are affected by our settings the same way
as we are ourselves.
We would create root account from sysusers or from firstboot, depending on
which one ran earlier. Since firstboot offers more options, in particular can
set the root password, we needed to order it earlier. This created an ugly
ordering requirement:
systemd-sysusers.service > systemd-firstboot.service > ... >
systemd-remount-fs.service > systemd-tmpfiles-setup-dev.service >
systemd-sysusers.service
We want sysusers.service to create basic users, so we can create nodes in dev,
so we can operate on block devices and such, so that we can resize and remount
things. But at the same time, systemd-firstboot.service can only work if it is
run early, before systemd-sysusers.service has created /etc/passwd. We can't
have it both ways: the units that want to have a fully writable root file
system cannot be ordered before units which are required to do file system
preparation.
Instead of trying to order firstboot very early, let's let it do its thing even
if it is started later. Instead of refusing to create to the root account if
/etc/passwd and /etc/shadow exist, actually check if the account is configured.
Now sysusers writes root account with password PASSWORD_UNPROVISIONED
("!unprovisioned"), and then firstboot checks for this, and will configure root
in this case.
This allows sysusers to be executed earlier (or accounts to be set up earlier
in another way).
This effectively reverts b825ab1a99.
The goal of this change is to delay getty services until after
systemd-vconsole-setup has finished. systemd-vconsole-setup starts loadkeys,
and it seems that when loadkeys is interrupted by the TTY hangup call we do
when starting tty services [1], so that loadkeys starts getting EIO from the
ioctl("/dev/tty1", KDSKBENT) syscall it does.
Fixes#26908.
[1] https://github.com/legionus/kbd/issues/92#issuecomment-1554451788
Initially I wanted to add ordering dependencies to individual units, but
TTYVHangup= can be added to other various external units too. The solution with
an implicit dependency should cover those cases too.
Doesn't matter much, but this makes it leas magic and independent of
/proc/ mounts. (Well, it actually doesn't, since the right-hand path is
also in /proc/, but still...
Let's be more accurate about what this function does: it checks whether
the underlying reported inode is the same. Internally, this already uses
a better named stat_inode_same() call, hence let's similarly name the
wrapping function following the same logic.
Similar for files_same_at() and path_equal_or_same_files().
No code changes, just some renaming.
The call is void anyway, it doesn't return an failure indication. Hence,
no need to cast void to (void)...
(We got this right in most cases, but forgot some)
The previous error code -ERANGE is slightly ambiguous, and use more
specific one. This also drops unnecessary error handlings.
Follow-up for 754d8b9c33 and
e652663a04.
If a container manager does not follow the guidance in
https://systemd.io/CONTAINER_INTERFACE/ regarding audit capabilities,
then the current check may not be sufficient to determine that audit
will function properly. In particular, when calling bind() on the audit
fd, we will get EPERM if running in a user-namespaced container.
Expand the check to make an AUDIT_GET_FEATURE request on the audit fd to
test if it is working. If this fails with ECONNREFUSED, we know it is
because the kernel does not support the use of audit outside of the
initial user namespace.
Note that the approach of this patch was suggested here:
https://github.com/systemd/systemd/pull/19443#issuecomment-829566659Fixes: #6519
The kernel has had filesystem independent reflink ioctls for a
while now, let's try to use them and fall back to the btrfs specific
ones if they're not supported.
Yu Watanabe
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Lennart Poettering
Frantisek Sumsal
David Tardon
Luca Boccassi
Sam James
Nick Rosbrook