Description of problem: Using programs that try to restore selinux context fail on nfs mounted filesystems. That means that things like prelink fail. Version-Release number of selected component (if applicable): 2.6.33.6-147.2.4.fc13.i686 How reproducible: Always Steps to Reproduce: 1. mount some nfs file system. 2. touch test1 test2 3. ls -lahZ test? -rw-rw-r--. mark mark system_u:object_r:nfs_t:s0 test1 -rw-rw-r--. mark mark system_u:object_r:nfs_t:s0 test2 4. $ cp --preserve=context test1 test2 cp: failed to set the security context of `test2' to `system_u:object_r:nfs_t:s0': Operation not supported Actual results: Preserving selinux security context fails. Expected results: Preserving selinux security context succeeds. Additional info: Same can be seen with tools like prelink: $ prelink -vfNR -r 0x6400000 libtest.so prelink: Could not set security context for libtest.so: Operation not supported But this should really just be a no-op since it is setting the (fake) selinux context already there. See for example this strace: $ strace -e lgetxattr,fsetxattr cp --preserve=context test1 test2 lgetxattr("test1", "security.selinux", "system_u:object_r:nfs_t:s0", 255) = 27 fsetxattr(4, "security.selinux", "system_u:object_r:nfs_t:s0", 27, 0) = -1 EOPNOTSUPP (Operation not supported) cp: failed to set the security context of `test2' to `system_u:object_r:nfs_t:s0': Operation not supported Would it be possible to make this work by letting selinux_inode_setxattr silently succeed on such (no-op) calls that just set the selinux context back to what it already was?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 WONTFIX if it remains open with a Fedora 'version' of '13'. 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 prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still an issue on Fedora 14. The reproducer from comment #1 still fails.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still an issue against 3.6.0-0.rc1.git2.1.fc18.x86_64: [mark@rawhide nfs]$ touch test1 test2 [mark@rawhide nfs]$ ls -lahZ test? -rw-rw-r--. mark mark system_u:object_r:nfs_t:s0 test1 -rw-rw-r--. mark mark system_u:object_r:nfs_t:s0 test2 [mark@rawhide nfs]$ cp --preserve=context test1 test2 cp: failed to set the security context of ‘test2’ to ‘system_u:object_r:nfs_t:s0’: Operation not supported [mark@rawhide nfs]$ uname -a Linux rawhide 3.6.0-0.rc1.git2.1.fc18.x86_64 #1 SMP Mon Aug 6 14:21:25 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [mark@rawhide nfs]$ strace -e lgetxattr,fsetxattr cp --preserve=context test1 test2 lgetxattr("test1", "security.selinux", "system_u:object_r:nfs_t:s0", 255) = 27 fsetxattr(4, "security.selinux", "system_u:object_r:nfs_t:s0", 27, 0) = -1 EOPNOTSUPP (Operation not supported) cp: failed to set the security context of ‘test2’ to ‘system_u:object_r:nfs_t:s0’: Operation not supported +++ exited with 1 +++
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still a problem with 3.9 based F19 kernels?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 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.
(In reply to comment #7) > This bug is being closed with INSUFFICIENT_DATA as there has not been a > response in 2 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. Grin. You asked for 3.9 based F19 kernels. The Alpha only came out today. But yes, this is still an issue. Just run the reproducer from comment #1: $ uname -a Linux f19 3.9.0-0.rc7.git3.1.fc19.x86_64 #1 SMP Thu Apr 18 20:29:47 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ touch test1 test2 $ ls -lahZ test[12] -rw-r--r--. mark root system_u:object_r:nfs_t:s0 test1 -rw-r--r--. mark root system_u:object_r:nfs_t:s0 test2 $ cp --preserve=context test1 test2 cp: failed to set the security context of ‘test2’ to ‘system_u:object_r:nfs_t:s0’: Operation not supported
The following https://fedoraproject.org/wiki/Changes/LabeledNFS might resolve this bug if it is implemented for F20.
*********** MASS BUG UPDATE ************** 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 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update 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.
Yes, this is still an issue, same reproducer: $ uname -a Linux f19 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ touch test1 test2 $ ls -lahZ test[12] -rw-rw-r--. mark mark system_u:object_r:nfs_t:s0 test1 -rw-rw-r--. mark mark system_u:object_r:nfs_t:s0 test2 [mark@f19 elfutils]$ cp --preserve=context test1 test2 cp: failed to set the security context of ‘test2’ to ‘system_u:object_r:nfs_t:s0’: Operation not supported
(In reply to Mark Wielaard from comment #0) > Using programs that try to restore selinux context fail on nfs mounted > filesystems. That means that things like prelink fail. > $ strace -e lgetxattr,fsetxattr cp --preserve=context test1 test2 > lgetxattr("test1", "security.selinux", "system_u:object_r:nfs_t:s0", 255) = > 27 > fsetxattr(4, "security.selinux", "system_u:object_r:nfs_t:s0", 27, 0) = -1 > EOPNOTSUPP (Operation not supported) > cp: failed to set the security context of `test2' to > `system_u:object_r:nfs_t:s0': Operation not supported > > Would it be possible to make this work by letting selinux_inode_setxattr > silently succeed on such (no-op) calls that just set the selinux context > back to what it already was? I wonder if a program might for example depend on such a setxattr failing as a way to determine filesystem support for file labels. It's a bit farfetched, but still--I'm a bit nervous about fooling with the established behavior of the kernel interface. Would it make sense to teach the tools to recognize this case instead?
Perhaps we should change the SELinux library call to check the label on a EOPNOPSUPP, if they patch return success.
Created attachment 801816 [details] something like the attached. We would need a similar patch for lsetfilecon.
*********** MASS BUG UPDATE ************** 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 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. 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 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
This has been fixed upstream in libselinux: commit 51d9a078c260b230f65863766e73e6db0b2c2d3a Author: Dan Walsh <dwalsh> Date: Wed Oct 9 15:15:35 2013 -0400 Patch to change *setfilecon to not return ENOSUP if context matches. Tools like cp -A try to maintain the context of a program and call *setfilecon, currently if the file system does not support XAttrs we return ENOSUPP. We have been requested to check if the context that is being set is the same to not return this error. So if I try to set the label on an nfs share to system_u:object_r:nfs_t:s0 and I get ENOSUPP, it will not return an error. Which seems to have made it into rawhide libselinux-2.2.2-5.fc21.x86_64 where the reproducer now works fine.