Support for AT_SYMLINK_NOFOLLOW in Systemd Bind Mounts about systemd

[YHNdnzj]

I don't understand what you are saying? Which mount API are you talking about?

Last time I looked Linux doesn't allow symlink inodes to either being overmounted nor can they be bind mounted on something else.

The new mount API (open_tree + move_mount) supports that: util-linux/util-linux@1b2d818

[andrewthad]

I see it now. This is the part I think you are referring to:

/* ExtensionImages/Directories are first opened in the propagate directory, not in the root_directory */
r = follow_symlink(!IN_SET(m->mode, MOUNT_EXTENSION_IMAGE, MOUNT_EXTENSION_DIRECTORY) ? root : NULL, m);
if (r < 0) {
        mount_entry_path_debug_string(root, m, error_path);
        return r;
}
if (r == 0) {
        /* We hit a symlinked mount point. The entry got rewritten and might
         * point to a very different place now. Let's normalize the changed
         * list, and start from the beginning. After all to mount the entry
         * at the new location we might need some other mounts first */
        again = true;
        break;
}

I'm not able to understand (not without spending more time looking at it) how follow_symlink rewrites the mount point, but the comment here insinuates that it does.

Here's a suggestion for how this might be made to work. Add a bool nofollow field to MountEntry. When nofollow is false, the behavior should be exactly as it is now. When nofollow is true, follow_symlink should still resolve symlinks in the path except for a symlink in the last piece of the path. So, in this new case, the rewritten path may not contain a symlink anywhere except in its last piece (e.g. in path /foo/bar/baz, foo and bar cannot be symlinks but baz can. And then, working back out toward the user-facing interface, both BindPaths and BindReadOnlyPaths would be lowered to MountEntrys with noresolve set to true, and for everything else, noresolve would be false.

This suggestion is a breaking change, but it makes the interface more consistent with tools like mount. To make it a nonbreaking change, systemd could instead introduce additional syntax (BindPaths=/foo:/bar:nofollow).

I'm happy to implement this if anyone can provide (or approve) for what shape this improvement should take.

[poettering]

I don't understand what you are saying? Which mount API are you talking about?

Last time I looked Linux doesn't allow symlink inodes to either being overmounted nor can they be bind mounted on something else.

Please provide an example in shell how you create a bind mount that overmounts a symlink inode.

[YHNdnzj]

Hmm, for your specific use case, i.e. bind mount over a target symlink, it is already supported? Which systemd version are you running?

[andrewthad]

Here's all the version information for the system I use:

systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

[andrewthad]

Sorry, disregard the previous information. That was run from the wrong system. Here's the systemd version that is used:

systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

And here is the output from uname -a:

Linux THEHOSTNAME 5.15.0-1038-raspi #41-Ubuntu SMP PREEMPT Fri Sep 8 12:38:39 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

[andrewthad]

Ubuntu 24 was just released, which includes systemd 255. I have been able to confirm that the same behavior is present there.

[YHNdnzj]

Hmm, right. I looked a bit closer and discovered that while we have the mount_nofollow_verbose helper that supports bind mounting over a symlink, setup_namespace -> apply_mounts always resolve the symlink first.