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.
There's little reason to require this, given that we can just say that
if a relative path is specified it is to be read relative to the root.
This fixes a bootctl bug introduced by
3730dc5d5b which didn't bother prefixing
paths as necessary.
Frantisek Sumsal
Yu Watanabe
Lennart Poettering
Samuel Thibault
Daan De Meyer
Jan Janssen
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Thomas Blume
Christian Brauner
Jonas Kümmerlin