I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
The function had just one caller and a name that didn't explain much.
Let's make it static and rename for clarity.
While at it, the only caller was not doing error handling correctly
— the function would potentially return a negative error value which
wasn't handled. In practice this couldn't happen, but let's remove
this ambiguity.
This reverts commit 7d4f00c88c.
fstype_can_uid_gid() is about fixating all files to the specified
uid/gid. tmpfs does not qualify. The uid/gid parameter there is simply
about the default uid/gid for the root inode of the tmpfs, it allows
setting uids/gid arbirarily for all inodes after that.
This distinction matters: for file systems this function returns true
for we can use this in place of uidmapped mounts. But for tmpfs this is
not going to work, given inodes on that fs can end up having arbitrary
uid/gid.
See: https://github.com/systemd/systemd/pull/25284#issue-1438427144
As tmpfs(5) says, both uid= and gid= are supported since kernel 2.5.7 and
the mount utility seems to agree:
```
# stat -c "%U:%G" mnt
root:root
# mount -o uid=testuser,gid=testuser -t tmpfs tmpfs mnt
# stat -c "%U:%G" mnt
testuser:testuser
```
However, systemd-mount currently complains:
```
# systemd-mount --owner testuser -t tmpfs tmpfs mnt
File system type tmpfs is not known to support uid=/gid=, refusing.
```
Often the fds that shall stay around in the child shall be passed
to a process over execve(), hence add an option to explicitly disable
O_CLOEXEC on them in the child.
In the Xen case, it's the hypervisor which manages kexec. We thus
have to ask it whether a kernel is loaded, instead of relying on
/sys/kernel/kexec_loaded.
Using fsopen()/fsconfig(), we can check if hidepid/subset are supported to
avoid the noisy logs from the kernel if they aren't supported. This works
on centos/redhat 8 as well since they've backported fsopen()/fsconfig().
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
This should be enough to make us remember that constraint. A more heavy-weight
approach like renaming the option to CHASE_WARN_NSS_LOOKUP would be possible,
but it'd make the callers quite verbose and doesn't seem worth it.
In general, log_syntax_internal() must keep errno unchanged. But the
call to log_syntax_callback() was added outside of the block protected
by PROTECT_ERRNO.
This is useful for systems which don't have any fsck.
We already skip emitting the fsck dependency when the fsck.$fstype helper
is missing, but fstab-generator doesn't necessarily know the fstype when
handling the root= parameter.
Previously, systemd-fsck was started for these mounts and then exited
immediately because it couldn't find the fsck.$fstype helper.