On 6/01/2016, 8:37 AM, "Jeff Boyce" <jboyce(a)meridianenv.com&gt; 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

> 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/...

> 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.

Cheers, Doug

On 7/01/2016, 8:22 AM, "Jeff Boyce" <jboyce(a)meridianenv.com&gt; wrote: > On 1/5/2016 5:44 PM, Douglas Brown wrote: >> On 6/01/2016, 8:37 AM, "Jeff Boyce" <jboyce(a)meridianenv.com&gt; 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/... > 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