With newer samba versions there is apparently a requirement of the new VFS to mount fdescfs with the nodup option. Samba mounts fdescfs under /var/run e.g /var/run/samba4/fd This interacts badly with /etc/rc.d/cleanvar which uses 'find /var/run ...' to delete files under /var/run. During startup - there appear to be various parts of the filesystem referenced under /var/run/samba4/fd so that the result is deletion of all files under paths such as /bin /sbin /etc /root Rather than pushing to try to stop samba mounting this where it wants - I'm filing this bug to see if it makes sense instead to make cleanvar safer, as potentially other packages may do this sort of thing in future anyway. I tried various -name & -path flags to exclude *samba4/fd/* etc -but 'find' doesn't seem to recognise these as normal names & paths. adding "-mount" to restrict find to the same device number as /var/run seems to work. e.g the relevant line in /etc/rc.d/cleanvar becomes: find /var/run -mount \( -type f -or -type s | -name log -and ! -name logpriv \) -delete see also discussion at https://forums.freebsd.org/threads/iocage-removes-files-at-startup.87733/
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=39e8c2a29a860bdb69ffcfbc06de4d4ad103b458 commit 39e8c2a29a860bdb69ffcfbc06de4d4ad103b458 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-02-13 04:56:17 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-02-13 04:56:17 +0000 cleanvar: Be more careful when cleaning up /var. The cleanvar script uses find -delete to remove stale files under /var, which could lead to unwanted removal of files in some unusual scenarios. For example, when a mounted fdescfs(5) is present under /var/run/samba/fd, find(1) could descend into a directory that is out of /var/run and remove files that should not be removed. To mitigate this, modify the script to use find -x, which restricts the find scope to one file system only instead of descending into mounted file systems. PR: 269213 MFC after: 1 week libexec/rc/rc.d/cleanvar | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
(In reply to Julian Noble from comment #0) This is really an unusual case, which should not happen for normal operations (the better way to do it is fdescfs's should be mounted by the rc script, by setting security.jail.mount_fdescfs_allowed to 1 for the jail). However, legitimate mounting of regular file systems under /var/run is pretty rare, and deleting files is a potentially dangerous operation to begin with, so it seems that we should be erring on the safe side by just restricting the script to perform operation on one file system only.
Is there any chance to MFC to releng/13.1?
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0699f0d43416776d87d20d7953b7d686f1e2e572 commit 0699f0d43416776d87d20d7953b7d686f1e2e572 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-02-13 04:56:17 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-02-20 06:16:20 +0000 cleanvar: Be more careful when cleaning up /var. The cleanvar script uses find -delete to remove stale files under /var, which could lead to unwanted removal of files in some unusual scenarios. For example, when a mounted fdescfs(5) is present under /var/run/samba/fd, find(1) could descend into a directory that is out of /var/run and remove files that should not be removed. To mitigate this, modify the script to use find -x, which restricts the find scope to one file system only instead of descending into mounted file systems. PR: 269213 (cherry picked from commit 39e8c2a29a860bdb69ffcfbc06de4d4ad103b458) libexec/rc/rc.d/cleanvar | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=04b24c1069a546056dc33fab1ce7b11d9bf89f14 commit 04b24c1069a546056dc33fab1ce7b11d9bf89f14 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-02-13 04:56:17 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-02-20 07:18:06 +0000 cleanvar: Be more careful when cleaning up /var. The cleanvar script uses find -delete to remove stale files under /var, which could lead to unwanted removal of files in some unusual scenarios. For example, when a mounted fdescfs(5) is present under /var/run/samba/fd, find(1) could descend into a directory that is out of /var/run and remove files that should not be removed. To mitigate this, modify the script to use find -x, which restricts the find scope to one file system only instead of descending into mounted file systems. PR: 269213 (cherry picked from commit 39e8c2a29a860bdb69ffcfbc06de4d4ad103b458) libexec/rc/rc.d/cleanvar | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
A commit in branch releng/13.2 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=57c37babde3664c81bc30ec5086092ae950aab49 commit 57c37babde3664c81bc30ec5086092ae950aab49 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-02-13 04:56:17 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-02-21 15:37:30 +0000 cleanvar: Be more careful when cleaning up /var. The cleanvar script uses find -delete to remove stale files under /var, which could lead to unwanted removal of files in some unusual scenarios. For example, when a mounted fdescfs(5) is present under /var/run/samba/fd, find(1) could descend into a directory that is out of /var/run and remove files that should not be removed. To mitigate this, modify the script to use find -x, which restricts the find scope to one file system only instead of descending into mounted file systems. PR: 269213 Approved by: re (cperciva) (cherry picked from commit 39e8c2a29a860bdb69ffcfbc06de4d4ad103b458) (cherry picked from commit 0699f0d43416776d87d20d7953b7d686f1e2e572) libexec/rc/rc.d/cleanvar | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
(In reply to rashey from comment #3) > Is there any chance to MFC to releng/13.1? This has been fixed in releng/13.2. As release 13.2 is coming, do you still have strong opinions to MFC it to releng/13.1 ?
Currently I have the service disabled as a temporary fix. I will wait for 13.2 release.