Hide Forgot
Description of problem: We use autofs for nfs mounted home directories. Since Fedora 24 (and probably updated Fedora 23?) the SELinux label of autofs nfs directory after mounting is unlabeled_t for first 30 seconds if only a subdir is accessed in this partition but not the root directory of that partition itself. This results in errors and access denied of some services, for example sendmail cannot access .forward of user accounts, and dovecot cannot access the home directory for mail folders and indexes. But this behavior is not limited to home directories, it applies to every autofs nfs partition. I am not sure what the reason is. It seems to me that SELinux labels are only read when the directory is accessed directly. When a subdirectory is accessed, then it seems to me that the attributes of the directory of the mountpoint are not read, this is why it shows label unlabeled_t. Then, after 30 seconds, something happens, because then the mountpoint directory changes it's SELinux label to the label of the exported directory. May be sync is running after 30 seconds and read the extended attributes of the directory and set it to the right value? And if the mountpoint directory is listed immediate after automount, e.g. with ls -l, then the extended attributes are read immediately and set right at this time, not only after 30 seconds? I am not sure which component is the right for this bug. Please reassign if you find a better one. Version-Release number of selected component (if applicable): kernel-4.7.2-201.fc24.x86_64 selinux-policy-3.13.1-191.14.fc24.noarch selinux-policy-targeted-3.13.1-191.14.fc24.noarch autofs-5.1.1-22.fc24.x86_64 nfs-utils-1.3.4-1.rc2.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Use a host as nfs server, name it for example mynfsserver. Create a partition to export, create a filesystem, mount it, and create a subdirectory and a file in it. lvcreate -n testpartition -L 1G system mkfs -t ext4 /dev/system/testpartition mount -t ext4 -o defaults /dev/system/testpartition /mnt/testpartition (umask 022; mkdir -p /mnt/testpartition/subdir ) (umask 002; echo "This is text" > /mnt/testpartition/subdir/abc.txt ) chcon -R -t var_t /mnt/testpartition exportfs -o rw,sync :/mnt/testpartition systemctl restart nfs-server systemctl status nfs-server exportfs -o rw,sync :/mnt/testpartition showmount -e 2. Use another host as nfs client, name it for example mynfsclient. The following steps must be done on mynfsclient. 3. Start autofs on mynfsclient (if not already running). 4. Access the file in the subdirectory over autofs nfs partition mount: ls -ldZ /net/mynfsserver/mnt/testpartition cat /net/mynfsserver/mnt/testpartition/subdir/abc.txt ls -ldZ /net/mynfsserver/mnt/testpartition sleep 10 ls -ldZ /net/mynfsserver/mnt/testpartition sleep 10 ls -ldZ /net/mynfsserver/mnt/testpartition sleep 10 ls -ldZ /net/mynfsserver/mnt/testpartition sleep 10 ls -ldZ /net/mynfsserver/mnt/testpartition 5. Wait until the remote partition is unmounted by automount, or unmount it by command: ls -ldZ /net/mynfsserver/mnt/testpartition umount /net/mynfsserver/mnt/testpartition ls -ldZ /net/mynfsserver/mnt/testpartition 6. Access the mountpoint itself: ls -ldZ /net/mynfsserver/mnt/testpartition ls -l /net/mynfsserver/mnt/testpartition ls -ldZ /net/mynfsserver/mnt/testpartition Actual results: Step 4: [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 2 root root system_u:object_r:autofs_t:s0 0 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# cat /net/mynfsserver/mnt/testpartition/subdir/abc.txt This is text [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# sleep 10 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# sleep 10 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# sleep 10 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:var_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# sleep 10 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:var_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition Step 6: [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 2 root root system_u:object_r:autofs_t:s0 0 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# ls -l /net/mynfsserver/mnt/testpartition insgesamt 20 drwx------. 2 root root 16384 12. Sep 14:38 lost+found drwxr-xr-x. 2 root root 4096 12. Sep 14:59 subdir [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:var_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition Expected results: In Step 4 /net/mynfsserver/mnt/testpartition should have SELinux label var_t instead of unlabeled_t immediately after access to files in this remote partition.
I have added a test to see if subdirectories of the mountpoint also contain the wrong SELinux label, but they contain the right selinux label, while at the same time the mountpoint contains the wrong label (and changes the label after 30 seconds after mount). I have created two sub-sub-directories and a file in it: (umask 022; mkdir -p /mnt/testpartition/subdir/subdir2/subdir3 ) (umask 002; echo "This is text subdir3" > /mnt/testpartition/subdir/subdir2/subdir3/abc.txt ) Then I have checked that the partition is not mounted (type autofs_t), then I access the file in the sub-sub-directory, then I first check the mountpoint directory and the subdirs and the mountpoint too (in the first 30 seconds). Here the results: [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 2 root root system_u:object_r:autofs_t:s0 0 12. Sep 23:13 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# cat /net/mynfsserver/mnt/testpartition/subdir/subdir2/subdir3/abc.txt This is text subdir3 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition/subdir drwxr-xr-x. 3 root root unconfined_u:object_r:var_t:s0 4096 12. Sep 23:11 /net/mynfsserver/mnt/testpartition/subdir [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition/subdir/subdir2 drwxr-xr-x. 3 root root unconfined_u:object_r:var_t:s0 4096 12. Sep 23:11 /net/mynfsserver/mnt/testpartition/subdir/subdir2 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition/subdir/subdir2/subdir3 drwxr-xr-x. 2 root root unconfined_u:object_r:var_t:s0 4096 12. Sep 23:11 /net/mynfsserver/mnt/testpartition/subdir/subdir2/subdir3 [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition After more than 30 seconds after mounting, the label of the mountpoint directory has changed to the right value (as in the test before). [root@mynfsclient ~]# ls -ldZ /net/mynfsserver/mnt/testpartition drwxr-xr-x. 4 root root system_u:object_r:var_t:s0 4096 12. Sep 14:59 /net/mynfsserver/mnt/testpartition So, only the mountpoint shows the wrong behavior.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This problem still exists on Fedora 25. Has anyone an idea how to solve it?
This problem still exists on Fedora 26, but the behavior has changed. If nfs server runs Fedora 25, then the label of nfs mount point is nfs_t in the first 30 seconds, instead of unlabeled_t. After 30 seconds nfs mount point label changes to the same label that exported mount point on nfs server has. If nfs server runs Fedora 26, then all files have label nfs_t, ignoring labels on nfs server. I have a bug report for this new problem, see bug #1478135. I don't know if it has the same reason.
Update: With kernel-4.13.4-200.fc26.x86_64 the same behavior as in previous versions still exists on Fedora 26. Since the problem reported in bug #1478135 doesn't occur since some weeks, autofs mount points have label unlabeled_t again for the first 30 seconds.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This problem still exists on Fedora 28.
Hi, Did you try it mount with "context=" mount option?
(In reply to Lukas Vrabec from comment #9) > Hi, > > Did you try it mount with "context=" mount option? No, because I don't want to set the SELinux context for all files in the nfs volume to the same value (if I understand right what this option does). The nfs files should have the same value as the files of the exported volume.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.