This nullfs feature has been requested in scattered places, so I thought we could have a bug to track progress that users can subscribe to. Examples: - https://lists.freebsd.org/pipermail/freebsd-questions/2020-December/292395.html (we can't null-mount a single file (useful to inject configs or sockets; linux has mount --bind for that)) - https://forums.freebsd.org/threads/how-to-share-a-regular-file-between-jails.70793/
This isn't covered by https://cgit.freebsd.org/src/commit/?id=521fbb722c33663cf00a83bca70ad7cb790687b3 ?
(In reply to Mark Johnston from comment #1) there is no MFC, unfortunately...
with FreeBSD 14 it works: # echo "foobar" > /tmp/foobar.txt # touch /tmp/mount.txt # mount_nullfs /tmp/foobar.txt /tmp/mount.txt # cat /tmp/mount.txt foobar # echo "more-foobar" > /tmp/mount.txt # cat /tmp/foobar.txt more-foobar # umount /tmp/mount.txt
Here it is: stable/14: 521fbb722c33663cf00a83bca70ad7cb790687b3 stable/13: d373650a53977de4aba1da737525bd37eeba72ca The commit in main lacks attribution and the backports lack cherry-pick attribution.
(In reply to Michael Osipov from comment #4) The commit in stable/14 is the same as the one in main, the feature appeared before stable/14 was created. The stable/13 commit has an annotation pointing to the original commit. What missing attribution are you referring to?
(In reply to Mark Johnston from comment #5) Yeah, it is only stable/14, but MFC is missing on main that is why I am surprised why it did find it on stable branches. Question is now: Is 521fbb722c33663cf00a83bca70ad7cb790687b3 on 14.0-RELEASE?
(In reply to Michael Osipov from comment #6) > Yeah, it is only stable/14, but MFC is missing on main that is why I am surprised why it did find it on stable branches. You mean the commit on main doesn't have a "MFC after" tag? Sure, that's fine. Sometimes one forgets to add it. > Question is now: Is 521fbb722c33663cf00a83bca70ad7cb790687b3 on 14.0-RELEASE? Yes.
(In reply to vini.ipsmaker from comment #0) As it seems everything is there, you should give it a try, no?
I've tested here on 14.0-RELEASE. It works for regular files, but it doesn't work for UNIX sockets: Output (after I started an UNIX socket server at /tmp/sock) # > /tmp/sock2 # mount_nullfs /tmp/sock /tmp/sock2 mount_nullfs: /tmp/sock: must be either a file or directory
It also doesn't work for character/block files (mknod): # mount_nullfs /dev/tty /tmp/mount.txt mount_nullfs: /dev/tty: must be either a file or directory Not the safest thing in the world to do (attack surface would be huge which would be hard to audit), but some clients don't care about that and would like to have containerized applications that can offload workloads to specialized hardware anyway (GPUs being one example). However it doesn't matter that much on FreeBSD (one can just call mknod directly before starting the jail I guess). I'm just mentioning for the sake of completeness because this also works on Linux (on Linux is more important because the way user/mount namespaces work).
(In reply to vini.ipsmaker from comment #10) It seems reasonable to allow mounting sockets and fifos but certainly not for devices - having device nodes outside of devfs has not worked since about FreeBSD 6.0 (as mentioned in the manual for mknod(1)). The correct way of exposing devices in jails is to use devfs rules to add specific nodes to the jail's devfs. For podman users, the '--device' argument to 'podman run' and 'podman create' is supported on FreeBSD and under the hood, it adds suitable devfs rules to the container jail.
> The correct way of exposing devices in jails is to use devfs rules to add specific nodes to the jail's devfs. For podman users, the '--device' argument to 'podman run' and 'podman create' is supported on FreeBSD and under the hood, it adds suitable devfs rules to the container jail. This seems very reasonable to me. So we only need null-mount support for UNIX sockets and FIFOs now.