While all distributions agree on where the basic rootfs symlinks
(/bin /sbin /lib) should point to, not all of them agree on the
target of /lib64. Debian and derivatives, expect something different
than Fedora et al. This is mostly due to the different way multiarch
vs multilib are designed.
This can lead to the situation where running systemd-nspawn on Fedora
to boot a Debian container creates an incompatible symlink in the guest
persistent, pre-created and pre-populated root filesystem, causing
issues due to these incompatibilities.
While it would be great if Debian and derivatives had the same
expectations as the rest of the world, this is baked in many places
and not likely to ever be fixable, as the multiarch vs multilib
behaviours are now very entrenched, and changing it would break
compatibilities left and right.
The core purpose of base-filesystem was to allow bringing up a system
with an empty/ephemeral/etc rootfs (and a /usr/ image on top). So as
a workaround, create /lib64 only if we detect that we have created
/bin /lib and /sbin, as that's a sure sign we are booting into an
empty rootfs that needs to be populated.
Conversely, if the filesystem _already_ has /bin /sbin and /lib,
it means it is not ephemeral and it is pre-prepared and persistent,
so it's a good idea to avoid second-guessing the image builder tool
or the package manager and override what it does, and just let them
carry on with the system however they configured it.
Reworked and reworded, original author: Helmut Grohne <helmut@subdivi.de>
On s390x both __s390__ and __s390x__ are defined, and with the original
order we'd go through the __s390__ branch and emit a warning:
[169/2118] Compiling C object src/shared/libsystemd-shared-256.a.p/base-filesystem.c.o
../src/shared/base-filesystem.c:136:11: note: ‘#pragma message: Please add an entry above specifying whether your architecture uses /lib64/, /lib32/, or no such links.’
136 | # pragma message "Please add an entry above specifying whether your architecture uses /lib64/, /lib32/, or no such links."
| ^~~~~~~
The error handling and fchmodat() invocation is pretty much the same in
the directory and symlink branches, hence make them the same.
No real change in behaviour. Just refactoring.
This also changes the open flags from
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_NOFOLLOW to
O_DIRECTORY|O_CLOEXEC. O_RDONLY is redundant, since O_RDONLY is zero
anyway, and O_DIRECTORY pins the acces mode enough: it doesn't allow
read()/write() anyway when specified. O_NONBLOCK is also pointless given
that O_DIRECTORY is specified, it has no meaning on directories. (It is
useful if we don't know much about the inode we are opening, and could
be a device node or fifo, but the O_DIRECTORY excludes that case.)
O_NOFOLLOW is dropped since there's really no point in blocking out the
initial entrypoint being a symlink. Once we pinned the the root of the
tree it might make sense to restrict symlink use below it, but for the
entrypoint itself it doesn't matter.
These inodes are going to be overmounted anyway, hence let's create them
with access mode 555, so that they are as close to being immutable as
regular UNIX access modes allow them to be. In other words: this takes
the "w" mode away for root. This of course usually has little effect --
unless CAP_DAC_OVERRIDE is dropped. But at the very least it makes the
point clear that inodes should be considered immutable.
(I intended to make this 0000 originally, but that doesn't work, as many
tools – including our own – have fallback paths that when they see
ENOENT in /proc/ they can handle this gracefully. But changing the mode
to 000 would turn this to EACCES - something they usually have no
fallback path for)
On distros like Arch and on carbonOS, libraries end up in /usr/lib.
Thus, /lib64 should point to /usr/lib. This commit adds this
functionality as a final fallback (if neither Debian-style nor
Fedora-style multilib can be detected)
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
RUN_WITH_UMASK was initially conceived for spawning externals progs with the
umask set. But nowadays we use it various syscalls and stuff that doesn't "run"
anything, so the "RUN_" prefix has outlived its usefulness.
Let's not allow anyone to look into /root/ if we create it via the
base-filesystem logic. i.e. change 0755 → 0750 as default access mode
for /root/, in case we create it if it happens to be missing.
https://wiki.debian.org/ArchitectureSpecificsMemo shows the triplet, but no the
linker paths. I used the linker path from Fedora.
$ ls -l /lib /lib64
lrwxrwxrwx. 1 root root 7 Aug 13 2020 /lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Aug 13 2020 /lib64 -> usr/lib64
$ ldd /bin/sh|grep ld
/lib/ld-linux-riscv64-lp64d.so.1 (0x0000003fb8185000)
$ ls -l /lib/ld-linux-riscv64-lp64d.so.1
lrwxrwxrwx 1 root root 19 Aug 4 19:28 /lib/ld-linux-riscv64-lp64d.so.1 -> ../lib64/ld-2.32.so
$ uname -r
5.10.6+
So even though the canonical linker path uses /lib/, we need the /lib64 symlink
to be present.
https://wiki.debian.org/ArchitectureSpecificsMemo shows the triplet, but no the
linker paths. I used the linker path from Fedora, but I can't look up the
linker paths for BE and 32 bit. At least the ifdef scaffolding is provided, so
it should be trivial to fill in if somebody has access to such a system.
$ ls -l /lib /lib64
lrwxrwxrwx. 1 root root 7 Jan 26 2021 /lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 26 2021 /lib64 -> usr/lib64
$ ldd /bin/sh|grep ld
/lib64/ld64.so.2 (0x00007fffa0a90000)
$ uname -r
5.14.9-200.fc34.ppc64le
Note that the macro defines listed in the wiki page don't match what I get
on Fedora: __PPC64__ vs. __ppc64__.
$ cpp -dM < /dev/null |grep -iE '__(powerpc|ppc)'|sort
#define __powerpc__ 1
#define __powerpc64__ 1
#define __PPC__ 1
#define __PPC64__ 1
First half of the fix for #14311.
I think this is going to be very annoying for our downstream maintainers.
Let's at least provide the ifdef scaffolding so that only filling in the
actual entries remains. The structure is copied from missing_syscall.h.
There are environments where /lib might not be necessary (think:
statically compiled portable service binary), hence don't insist on it
if the image is read-only.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Previously we were a bit sloppy with the index and size types of arrays,
we'd regularly use unsigned. While I don't think this ever resulted in
real issues I think we should be more careful there and follow a
stricter regime: unless there's a strong reason not to use size_t for
array sizes and indexes, size_t it should be. Any allocations we do
ultimately will use size_t anyway, and converting forth and back between
unsigned and size_t will always be a source of problems.
Note that on 32bit machines "unsigned" and "size_t" are equivalent, and
on 64bit machines our arrays shouldn't grow that large anyway, and if
they do we have a problem, however that kind of overly large allocation
we have protections for usually, but for overflows we do not have that
so much, hence let's add it.
So yeah, it's a story of the current code being already "good enough",
but I think some extra type hygiene is better.
This patch tries to be comprehensive, but it probably isn't and I missed
a few cases. But I guess we can cover that later as we notice it. Among
smaller fixes, this changes:
1. strv_length()' return type becomes size_t
2. the unit file changes array size becomes size_t
3. DNS answer and query array sizes become size_t
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76745
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
If we are working on a path that was marked to be ignored on errors, and
the mkdirat() fails then add a continue statement and skip fchownat() call.
This avoids the case where UID/GID are valid and we run fchownat() on
non existent path which will fail hard even on paths that we want to
ignore in case of errors.
When a service is started with its own file system image, always try to
create the base-filesystem directories that are needed. This implicitly
covers the directories handled by MountAPIVFS= {/proc|/sys|/dev}.
Mount protections or MountAPIVFS= mounts were never applied if we
changed the root directory and the related paths were not present under
the new root. The mounts were silently. Fix this by creating those
directories if they are missing.
Closes https://github.com/systemd/systemd/issues/5488
