| Summary: | SELinux label of autofs mounted directory nfs_t for first 30 seconds if subdir is accessed | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Edgar Hoch <edgar.hoch> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | dominick.grift, dwalsh, edgar.hoch, goeran, lvrabec, plautrba |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-28 23:58:20 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Edgar Hoch
2016-09-12 13:14:39 UTC
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. |