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