On 1/5/2016 5:44 PM, Douglas Brown wrote:

On 6/01/2016, 8:37 AM, "Jeff Boyce" jboyce@meridianenv.com 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/htm...

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.

...

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?

Cheers, Doug

Thanks for you input, now I have a new tool to verify selinux problems before jumping to conclusions.

Jeff

On 1/6/2016 3:34 PM, Douglas Brown wrote:

On 7/01/2016, 8:22 AM, "Jeff Boyce" jboyce@meridianenv.com wrote:

...

On 1/5/2016 5:44 PM, Douglas Brown wrote:

...

On 6/01/2016, 8:37 AM, "Jeff Boyce" jboyce@meridianenv.com 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/htm...

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

@Lukas Thanks for reminding me of a basic diagnostic tool that I forgot to check. I temporarily put selinux into permissive mode, reproduced the problem (still denied saving), and see nothing showing up in the audit logs. This confirms that it is not a selinux problem. I am now following the theory presented by @Doug that it is a new Windows issue. The desktop system that the problem originally surfaced on is the first (and so far only) Window 10 box in the office. I would stop by Bill's house on my way home and complain, but it probably wouldn't help.

Thanks for everyone's help.