Re: [BUG] restorecon of a single file can trigger systemd automounts

On Thu, Jul 23, 2026 at 2:15 PM Félix-Antoine Fortin
<[email protected]> wrote:
>
> Hi,
>
> I encountered an unexpected side effect in restorecon: processing a
> single local file triggers unrelated automounts.
>
> Command (called during ipa-client-install):
>
>   $ restorecon /etc/krb5.conf.d/freeipa
>
> Although the target is under /etc, this causes all of the following
> NFS automounts to activate:
>
>   nfs-home.automount
>   nfs-project.automount
>   nfs-scratch.automount
>
> The journal identifies restorecon as the process that triggered each automount:
>
>   systemd[1]: nfs-home.automount: Got automount request for /nfs/home,
> triggered by 10521 (restorecon)
>   systemd[1]: Mounting /nfs/home...
>   nfsrahead[10530]: setting /nfs/home readahead to 128
>   systemd[1]: Mounted /nfs/home.
>   systemd[1]: nfs-project.automount: Got automount request for
> /nfs/project, triggered by 10521 (restorecon)
>   systemd[1]: Mounting /nfs/project...
>   nfsrahead[10533]: setting /nfs/project readahead to 128
>   systemd[1]: Mounted /nfs/project.
>   systemd[1]: nfs-scratch.automount: Got automount request for
> /nfs/scratch, triggered by 10521 (restorecon)
>   systemd[1]: Mounting /nfs/scratch...
>   nfsrahead[10536]: setting /nfs/scratch readahead to 128
>   systemd[1]: Mounted /nfs/scratch.
>
> The fstab entries are:
>
>   nfs_server:/home /nfs/home nfs4
> proto=tcp,nosuid,nolock,noatime,actimeo=3,nfsvers=4.2,seclabel,_netdev,x-systemd.automount,x-systemd.mount-timeout=30
> 0 0
>   nfs_server:/project /nfs/project nfs4
> proto=tcp,nosuid,nolock,noatime,actimeo=3,nfsvers=4.2,seclabel,_netdev,x-systemd.automount,x-systemd.mount-timeout=30
> 0 0
>   nfs_server:/scratch /nfs/scratch nfs4
> proto=tcp,nosuid,nolock,noatime,actimeo=3,nfsvers=4.2,seclabel,_netdev,x-systemd.automount,x-systemd.mount-timeout=30
> 0 0
>
> An strace shows restorecon probing these mountpoints:
>
>   $ strace -f restorecon /etc/krb5.conf/freeipa 2>&1 | grep /nfs
>
>   statfs("/nfs/home", {f_type=NFS_SUPER_MAGIC, f_bsize=1048576,
> f_blocks=10172, f_bfree=10069, f_bavail=10069, f_files=5240832,
> f_ffree=5240755, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=1048576,
> f_flags=ST_VALID|ST_NOSUID|ST_NOATIME}) = 0
>   statfs("/nfs/project", {f_type=NFS_SUPER_MAGIC, f_bsize=1048576,
> f_blocks=10172, f_bfree=10069, f_bavail=10069, f_files=5240832,
> f_ffree=5240816, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=1048576,
> f_flags=ST_VALID|ST_NOSUID|ST_NOATIME}) = 0
>   statfs("/nfs/scratch", {f_type=NFS_SUPER_MAGIC, f_bsize=1048576,
> f_blocks=10172, f_bfree=10069, f_bavail=10069, f_files=5240832,
> f_ffree=5240818, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=1048576,
> f_flags=ST_VALID|ST_NOSUID|ST_NOATIME}) = 0
>
> My understanding is:
>
> 1. When restorecon is called without ignore mount (-m) flag, it reads
> the mount table to construct the exclusion list for filesystems
> without SELinux labeling support.
> https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L146C14-L146C28
> 2. exclude_non_seclabel_mounts() calls file_system_count() for mounts that
> advertise the seclabel option. file_system_count() calls statvfs() on
> the mountpoint.
> https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L343
> https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L282
> 3. Calling statvfs() on a autofs mountpoint activates the underlying mount.
> 4. The resulting file count appears to be used only for progress reporting, but
> it is calculated even when neither progress nor mass-relabel reporting
> was requested.
>
> So a non-recursive restorecon operation on one local file can mount
> unrelated remote filesystems.
>
> I would expect restorecon to not activate unrelated systemd automount
> filesystems when progress reporting is not requested and the target
> does not traverse those filesystems.
>
> Environment:
>
> Distribution: AlmaLinux release 9.8 (Olive Jaguar)
> policycoreutils package: policycoreutils-3.6-5.el9.x86_64
> libselinux package: libselinux-3.6-3.el9.x86_64
> systemd package: systemd-252-67.el9_8.4.alma.1.x86_64
> Kernel: 5.14.0-687.26.1.el9_8.x86_64
>
> Let me know if I can be of further assistance.
> Félix-Antoine Fortin

Thanks for the report. Do you intend to submit a patch to fix this or
are you asking us to do so?
Regardless, you should also file a bug against your distribution to
ensure that it ultimately gets
fixed there.