Description of problem: Some time ago the kernel got the ability to forward SELinux labels over NFS. (For a short while I believe it was the default, but then later changed to an opt-in functionality.) I had this working for a while, but it isn't any more. Version-Release number of selected component (if applicable): kernel-4.11.9-300.fc26.x86_64 nfs-utils-2.1.1-5.rc2.fc26.x86_64 How reproducible: Every time Steps to Reproduce (on a single host): 1. Export /usr/local with the security_label option: [root@mimmi Hämtat]# exportfs -s | grep local /usr/local 172.17.0.0/18(rw,sync,wdelay,hide,no_subtree_check,security_label,sec=sys,secure,no_root_squash,no_all_squash) 2. Mount it with the seclabel option: [root@mimmi Hämtat]# mount -o seclabel,vers=4.2 mimmi:/usr/local /mnt 3. List the labels in the mounted directory: [root@mimmi Hämtat]# ls -lZ /mnt totalt 160 drwxr-xr-x. 3 root root system_u:object_r:nfs_t:SystemLow 4096 6 aug 17.31 bin drwxrwxr-x. 27 göran familj system_u:object_r:nfs_t:SystemLow 4096 6 jul 16.18 böcker drwxr-s---. 11 göran göran system_u:object_r:nfs_t:SystemLow 4096 14 feb 22.46 'D&D' drwxr-xr-x. 2 root root system_u:object_r:nfs_t:SystemLow 4096 1 aug 2003 doc drwxr-xr-x. 3 root root system_u:object_r:nfs_t:SystemLow 4096 31 jul 15.43 etc ... Actual results: All files and directories in the mounted have the SELinux type nfs_t. Expected results: The files should have the same types as in the source /usr/local directory (usr_t mostly, some of them bin_t or lib_t).
I got it to work by exporting entire filesystems - it would not work with subdirectories of mount points. This page says you need to set fsid=0: https://selinuxproject.org/page/Labeled_NFS But if you export root it automatically gets fsid 0, others just get a UUID and everything seems to work. (check /proc/fs/nfsd/exports)
Thanks for the tip Chuck. Unfortunately, after reading that and experimenting a bit, I'm even more confused! The page you referred to is a bit old it seems. Some google hits I found suggested fsid=0 wasn't needed any more. But it was a bit confusing as I said. I'm also uncertain where to put this fsid=0 in my actual case. The server has one big file system containing (almost) everything mounted as /. From it, I export a handful of directories (/home, /var/spool/mail, /usr/local, etc.). I also have a /remote/pluto which is the root file system of a diskless client. Which one of these should have the fsid=0? All of them? Do I have to export / from the server for security labels to work? As an experiment, I did exactly that, on the command line adding an export of / to one client. I didn't include fsid=0, but did include security_label. On the client I mounted that under /mnt. I do indeed see the security labels. Then I tried to unmount and again mount a couple of the directories normally mounted on the client. In one case the security labels show up. On the other, all the files show up as "unlabeled_t"! Did I mention I got even more confused? I didn't mean this to become a request for help. It did work previously, without exporting the entire file system and without fsid=0 anywhere. It did look like a regression to me; I thought it was a bug.
I investigating a bit more, using the following export from a host "freddi": / 172.17.0.0/18(rw,sync,no_root_squash,security_label) If I do mount -o seclabel,vers=4.2 freddi:/ /mnt I see the correct security labels. If I create a directory /tmp/etc and do mount -o seclabel,vers=4.2 freddi:/etc /tmp/etc I still see the correct security labels. If I also make a directory /tmp/usr and do mount -o seclabel,vers=4.2 freddi:/etc /tmp/etc mount -o seclabel,vers=4.2 freddi:/usr /tmp/usr all files in both trees show up with the type unlabeled_t. Is this really the intended behaviour?
I had a similar problem - see bug 1478135. The problem has disappeared in the last weeks - I don't know why but I think some of updated packages has solved it. Have you installed all updates now?
I had not updated to the latest version. Unfortunately, doing so doesn't help. The test cases in comment 3 behave as before. Case 1 and 2, where i mount only one directory, works as expected. But mounting two directories, as in case 3, makes everything become "unlabeled_t". (Note that you need to unmount everything between each test, and mount both directories before checking. If you do e.g. "ls" in a mounted directory, the attributes from that directory are cached, and may hide the problems for a while.) kernel-4.12.9-300.fc26.x86_64 nfs-utils-2.1.1-5.rc5.fc26.x86_64
Ok, it is a different problem than mine. I have tried your test case 2 of comment #3. I see type unlabeled_t too. But if I don't export "/", but using two exports like /etc 172.17.0.0/18(rw,sync,no_root_squash,security_label) /usr 172.17.0.0/18(rw,sync,no_root_squash,security_label) then mounting as in case 2 works fine. Then I see the correct selinux labels. A personal note: Why do you want to export the whole file tree starting from / with write permissions and no root squash? From a security point of view I think this is a very bad idea. Every system in the subnet can manipulate even the running kernel memory on the nfs server (at least in theory, I didn't try it), because you even export /dev, /proc/, /sys, etc. with full root access. If you want to share /etc or /usr, I would export them read-only, and use some overlay fs on it if clients need to write files on them. If you want to use diskless systems, then each client should have at least its own directory for /etc and /var in directory or partition different from nfs servers /etc and /var directories.
Interesting! Exporting /etc and /usr separately does indeed work. But only one level below the root of the file system! Here is a fourth test case. Export /usr/bin only: /usr/bin 172.17.0.0/18(rw,sync,no_root_squash,security_label) Mount it on the client side: mount -o seclabel,vers=4.2 freddi:/usr/bin /mnt Now it fails again. In a slightly different way, the files don't show up with unlabeled_t this time, but with nfs_t. But labels are not exported, all the same. As for wanting to export the root file system. It's not what I really want to do in most cases. (In one case I backup a client by mounting its root on a server and backing up that way.) All the hosts involved have the same administrators, and "trust" each other anyway. But I tried to test the behaviour, and to create a simplified test case. (Maybe too simplified as it turns out.)
I can confirm that there is still a problem with nfs and selinux labels with current updated Fedora 26. - If the mount point of a local file system is exported, excluding "/", using export option security_label, then selinux labels are forwarded to nfs clients for nfs mounts of the exported mount point or a subdirectory of this. - Exporting "/" does not forward selinux labels. - If a direct subdirectory of "/" (first level) is exported, then selinux labels are forwarded to nfs clients for nfs mounts of this exported subdirectory or a subdirectory of this. - Exporting only a subdirectory of a local file system does not forward selinux labels. But if exporting the mount point of the local file system too, then a nfs mount of the exported subdirectory contains the forwarded selinux labels. About test case of comment #7: Try to export "/usr" in addition to "/usr/bin", then the client side should see the forwarded labels.
Thanks for that suggestion, Edgar Hoch! It was a combination I hadn't tried, and it does indeed work. It makes it possible for me to work around the issue in my actual use cases. (I have to export a bit too much. But as I mentioned above, it doesn't really matter in this context.)
Edgar Hoch's nice workaround doesn't seem to work any more. I have upgraded to kernel-4.13.13-300.fc27.x86_64 selinux-policy-3.13.1-283.17.fc27.noarch After reboot, all NFS files on the client, apparently regardless of level in the tree this time, are back to "unlabeled_t".
(In reply to Göran Uddeborg from comment #10) > Edgar Hoch's nice workaround doesn't seem to work any more. I have upgraded > to > > kernel-4.13.13-300.fc27.x86_64 > selinux-policy-3.13.1-283.17.fc27.noarch > > After reboot, all NFS files on the client, apparently regardless of level in > the tree this time, are back to "unlabeled_t". I cannot confirm this. On my systems the nfs client behaviour with these packages is the same as before.
Ok, so I have messed something up again. I'll dig into it again, and report if it seems relevant to anyone else.
When I boot the client with an old 4.12.9-300.fc26.x86_64 kernel, it does see the labels again. When I boot with 4.13.13-300.fc27.x86_64 or (4.13.6-300.fc27.x86_64). It's the same client, the same selinux version (3.13.1-283.17.fc27), and the same userspace otherwise. Only different kernels are chosen at boot. The server is running 4.13.13-300.fc27.x86_64 in all three cases. I wonder why it works for you, Edgar, but not for me.
I tried kernel 4.14.8-300.fc27, but with that the files also show up as "unlabeled_t". Going back to 4.12.9-300.fc26 it still works as it should, with "user_home_t" in the home directories etc.
Another data point: On a different client box (F26, mainly running MythTV) I tried the kernel 4.14.11-200.fc26. Then the label forwarding disappeared, and I was back to "nfs_t". Going back and booting 4.12.14-300 I see normal labels again. This is a diskless client which has nfs root. It mounts /remote/pluto which is exported like this from the server, same server as above: /remote pluto(rw,sync,no_root_squash,security_label) /remote/pluto pluto(rw,sync,no_root_squash,security_label) The file system /remote is exported following the advice in comments in this bugzilla; nothing actually mounts /remote directly.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs. Fedora 26 has now been rebased to 4.15.4-200.fc26. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27. If you experience different issues, please open a new bug report for those.
I still experience this problem with kernel-4.15.6-300.fc27.x86_64. If I mount just one piece of a file system from a server, I see labels. If I mount a second part of the same file system, everything shows up as unlabeled_t. As there have been several variants here, this is the test case I used here: - The NFS server, has a single large file system mounted as /. - Freddi exports like this: /etc 172.17.0.0/18(rw,sync,no_root_squash,security_label) /usr 172.17.0.0/18(rw,sync,no_root_squash,security_label) - On the client, do mkdir /tmp/{etc,usr} mount freddi:/etc /tmp/etc ls -lZ /tmp/etc # Shows the proper labels mount freddi:/usr /tmp/usr ls -lZ /tmp/usr # Everything shows up with unlabeled_t ls -lZ /tmp/etc/dnf # Also shows up with unlabeled_t now ls -lZ /tmp/etc # Still looks good, because of caching I assume
In addition, if the client runs (the by now pretty old) kernel 4.12.9-300.fc26.x86_64, labels are properly forwarded again. They are forwarded even if the NFS server is running 4.15.6-300.fc27.x86_64.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
I tried the test case from comment 17 with kernel-4.17.7-200.fc28.x86_64 on both server and client. The problem remains unchanged.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.18.10-300.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
I tried the test case from comment 17 with kernel-4.18.10-300.fc29.x86_64 on both server and client. The problem remains unchanged.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 4.19.5-300.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The test case from comment 17 with kernel-4.19.6-300.fc29.x86_64 still exhibits broken behaviour when the second mount is done; there is no improvement.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 4.20.5-200.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The test case from comment 17 with still exhibits broken behaviour with kernel-4.20.13-200.fc29.x86_64; there is no improvement.
I just discovered that NFSv4 allowed exporting the SELinux contexts (I was configuring a Mediawiki over an NFS-exported folder and wanted to export the correct "mediawiki_content_t" to the machine actually running the httpd server) and I stumbled into this very same bug: a SELinux-enabled CentOS 7 server correctly exports via NFSv4 the security contexts of all files and subfolders to a SELinux-enabled CentOS 7 client ONLY if that export is the only one on the server - as soon as a second folder is exported between the same two machines, the context of some files (mostly those in subfolders) becomes "unlabeled_t".
Following the suggestion here: https://serverfault.com/a/554949/516112, I don't understand why (I was under the impression that 'nosharecache' should be used when mounting mutiple times the same NFS export while at the same time forcing an explicit, different SELinux context by means of the mount options per each mount, which is NOT the case here) but actually adding 'nosharecache' to the NFS client's mount options fixes the problem of wrong and inconsistent SELinux contexts in subfolders of multiple NFS exports, at least here.
Thanks for that tip, Francesco! It does indeed seem to be a way to work around the problem. It still looks like a bug to me. The description of the option states "Using the same cache [...] presents identical file contents to applications when the same remote file is accessed via different mount points." I DO expect the same file to have the same SELinux label if accessed via different mount points. It sounds like it should be fine to share the cache. I'll keep the bug open until I find a clear statement this is indeed the intended behaviour, and hopefully an explanation why. But in the mean time, there is a workaround. Thanks for that!
(In reply to Göran Uddeborg from comment #29) > Thanks for that tip, Francesco! It does indeed seem to be a way to work > around the problem. Glad I could be of help! > It still looks like a bug to me. The description of the option states > "Using the same cache [...] presents identical file contents to applications > when the same remote file is accessed via different mount points." I DO > expect the same file to have the same SELinux label if accessed via > different mount points. It sounds like it should be fine to share the cache. I completely agree; unless a clarification appears regarding what's in the documentation, observed behaviour is at odds with what is described, therefore there is a bug. > I'll keep the bug open until I find a clear statement this is indeed the > intended behaviour, and hopefully an explanation why. But in the mean time, > there is a workaround. Thanks for that! Very well; I don't know if you can modify here to include CentOS 7, which is where I'm experiencing this same issue (I see that your server is Fedora-based).
> I don't know if you can modify here to include CentOS 7 AFAIK a bug belongs to a single "product" and a single "version" of that product. I'm not sure it really matters; if it gets fixed for Fedora, the fix will probably find its way to CentOS too. If you wish anyway, I believe the normal procedure is to "clone" the bug to a different product/version in cases like this. Feel free to do that if you wish! :-) There ise a little button to do that in the upper right hand corner.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 5.2.9-100.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Sorry for not testing this earlier. I didn't have the time when the request came. But now I've repeated the test from comment 17, using the F31 kernel 5.3.0-1.fc31.x86_64. And finally, it works! That is, even without the "nosharecache" workaround. I didn't test 5.2.9.