On 7/01/2016, 8:22 AM, "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx> wrote: >On 1/5/2016 5:44 PM, Douglas Brown wrote: >> On 6/01/2016, 8:37 AM, "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx> wrote: >> >>> Greetings - >>> >>> A coworker ran into a (permission denied) problem recently trying to >>> save a file on our Samba server. So I first checked into the normal >>> user and group permissions for the user and the file, and everything >>> seemed fine there. So then I moved on to investigating whether it was >>> an SELinux issue, and subsequently I think I found more problems on our >>> Samba server than I wanted to see. >>> >>> A short description of the issue that I see is that while the files on >>> my Samba share are labeled with the samba_share_t type, there is a >>> mixture of two different SELinux user labels. Some directories/files >>> are labeled with system_u and others are labeled with unconfined_u. The >>> particular file that the coworker was trying to save (and received a >>> permission denied result) had a system_u label. An example of the >>> mixture is shown below. >>> >>> [root@sequoia CorporateDocs]# ls -lZ >>> drwxrws--T. eileenm mei_office system_u:object_r:samba_share_t:s0 Amendments >>> drwxrws--T. jeffb meiboard unconfined_u:object_r:samba_share_t:s0 >>> Budget Materials >>> -rwxrw----. eileenm mei_office system_u:object_r:samba_share_t:s0 >>> Ltr_Engagement_Mclanahan.pdf >>> drwxrws--T. jeffb meiboard unconfined_u:object_r:samba_share_t:s0 MEI >>> Stock >>> -rwxrw----. eileenm mei_office system_u:object_r:samba_share_t:s0 >>> Original By-laws.pdf >> Redhat distributions only use the user label in the process of mapping Linux users to available roles (RBACs), so it must be a coincidence. >> >>> Our setup in this small office includes a Samba file server that is >>> accessed by all staff through their Windows desktop/laptop systems. We >>> have a half a dozen main directories under our primary share with only >>> one of them restricted to a subset of the staff as diagrammed below. >>> The restricted subset is defined by standard user and group restrictions. >>> >>> Ecosystem Share >>> Projects - all staff >>> Proposals - all staff >>> Reference - all staff >>> CorporateAdmin - restricted subset of staff >>> >>> I suspect that the mixture of selinux user labels was a result of our >>> migration to this CentOS 6 server (a KVM guest if that matters) a couple >>> years ago from a pre-selinux RHEL 3 server. I thought I had all my >>> Samba selinux settings setup correctly when doing the migration, but I >>> guess not. I am actually surprised that we haven't run into the issue >>> earlier. >> To demonstrate that the issue isn’t related to the user labels, you can restore them to system_u like so: restorecon -RF /ecosystem >I am going to look into this options a little more, but since it likely >isn't causing a problem I may just leave everything the way it is until >I can tests things without everyone on the system. > >>> My goal now is to get all the selinux user labels uniformly correct and >>> solve the permission denied error that my coworker encountered. I am >>> hoping the first solves the second, and doesn't conflict with it. >>> Although I am not sure which label is correct for my situation, system_u >>> or unconfined_u. And if it is system_u, then why the permission denied >>> issue on that particular file. They don't have the same issue with >>> other files in other directories that have a system_u label. >> This probably isn’t an SELinux issue but if you replicate it, then run this as root: >> >> ausearch -ts recent | audit2allow >> >> >> and it comes back with nothing then it’s almost certainly not SELinux denying the access; having said that, it’s good to also be aware of this when diagnosing issues: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Possible_Causes_of_Silent_Denials.html >Well I started with the suggestion here of disabling the don't audit >rules to see what would show up in the logs. I had the user open the >file and try to save it, which resulted in the same permissions error. >Looking through all the log files, there was nothing that matched this >activity, or the timing of the activity, leading me to believe that it >is not a SELinux issue. Then I had the person repeat the exercise when >I had an opportunity to see their screen, and lo and behold the error >dialog box indicates that the error is being generated by MS Excel. >Further investigation of the error has led me down a black hole. Within >Windows and Linux, the user has the exact same permissions as me, yet I >can save the file and they can't. There has to be some hidden >permission parameters on that file somewhere, but I have given up and we >are working around it. A few months ago I saw a permissions issue with files on a NetApp CIFS share when written to by recent Windows versions (8/10?) then accessed by older Windows versions. >>> I have read through the RHEL SE Linux User guide an am not sure where to >>> go from here. So I am looking for some guidance from the experts here. >>> I looked into the >>> /etc/selinux/targeted/contexts/files/file_contexts.local file and see >>> the following information. Maybe this is messed up also; or a >>> contributing factor to my issue. >>> >>> # This file is auto-generated by libsemanage >>> # Do not edit directly. >>> /ecosystem(/.*)? system_u:object_r:samba_share_t:s0 >>> /home/jeffb/messages system_u:object_r:user_home_t:s0 >>> ./CorporateDocs system_u:object_r:samba_share_t:s0 >> The last two entries are odd. >I thought they looked odd also, especially since there is no >/home/jeffb/messages directory, and I don't recall there ever being >one. This is something that I should probably clean up since it affect >how things would be relabeled. So the follow-up question would be, what >is the appropriate method for correcting (deleting?) these last two entries? semanage fcontext -d /home/jeffb/messages semanage fcontext -d ./CorporateDocs >> Cheers, >> Doug >Thanks for you input, now I have a new tool to verify selinux problems >before jumping to conclusions. No worries, glad to help. :) Cheers, Doug > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
