IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
When compiling with -D utmp=false the compilation fails with:
../../git/systemd/src/test/test-utmp.c: In function ‘test_dump_run_utmp’:
../../git/systemd/src/test/test-utmp.c:21:9: error: cleanup argument not a function
21 | _unused_ _cleanup_(utxent_cleanup) bool utmpx = false;
| ^~~~~~~~
../../git/systemd/src/test/test-utmp.c:23:17: error: implicit declaration of function ‘utxent_start’ [-Werror=implicit-function-declaration]
23 | utmpx = utxent_start();
| ^~~~~~~~~~~~
any many other errors
Add a conditional to compile test-utmp.c only if ENABLE_UTMP is true.
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.
```
flock(2) works with file descriptors opened with O_RDONLY.
This affects SELinux systems where access to block devices is quite
restricted to avoid bypasses on filesystem objects.
GitHub Action `devel-freezer` helps with development freeze notifications
during the RC phase. It will create comments using predefined messages on
newly created and updated PRs when the RC tag has been released.
Also, it will update comments once a new major version has been released.
Documentation available at: https://github.com/redhat-plumbers-in-action/devel-freezer
fsck(8) is located in /usr/sib/ on Debian sid:
stdout:
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-01-dev-nfs.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-02-dhcp.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-03-dhcp6.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-04-nfs.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-05-nfs4.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-06-ipv4.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-07-ipv6.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-08-implicit-nfs.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-09-cifs.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-10-iscsi.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-11-live.input
*** Running /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-12-dev-sdx.input
--- /dev/fd/63 2022-11-04 15:39:13.131532174 +0100
+++ /dev/fd/62 2022-11-04 15:39:13.131532174 +0100
@@ -6,3 +6,4 @@
initrd-usr-fs.target.requires
initrd-usr-fs.target.requires/sysroot.mount
sysroot.mount
+systemd-fsck-root.service
**** Unexpected output for /home/christian/Coding/workspaces/systemd/test/testdata/test-fstab-generator/test-12-dev-sdx.input
stderr:
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on NFS was requested.
Skipping root directory handling, as root on CIFS was requested.
Skipping root directory handling, as root on iSCSI was requested.
Skipping root directory handling, as root on live image was requested.
Found entry what=/dev/sdx1 where=/sysroot type=n/a opts=ro
Checking was requested for /dev/sdx1, but the fsck command does not exist.
Since f7725647bb when dissecting a disk
image we operate with fds to the device nodes in question wherever we
can. This includes when we fork off fsck, where we pass a /proc/self/fd/
path as argument. This only works if we keep that fd open however and
disable O_CLOEXEC on the fd. Hence do so, and fix fsck this way.
(Without this, all fsck will fail, since the fd path is invalid)
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.
On a read-only filesystem creating /root/.ssh might fail, but that's ok.
Do not fail the run, as this is only needed to add the credential, which
is a separate step.
In my understanding user group "3" (aka "sys") is kept for historical reasons
but not really useful these days. That's probably explained why this group
isn't defined on openSUSE.
Hence let's drop reference to this user group, this shouldn't lessen the
revelance of the test since SupplementaryGroups= is still tested with 2 other
groups.
This adds an additional name check when cross-matching new group
entries against existing users, which allows coalescing entries
matching both ID and name.
It provides a small idempotence enhancement when creating groups
in cases where matching user entries are in place. By fine-tuning
the conflict detection logic, this avoids picking up new random
IDs and correctly prefers configuration values instead.
