Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Something I'm attempting to run in RHEL6 fails as a result of SELinux. The problem is temporarily easily solved with "setenforce 0". However turning SELinux off entirely isn't an option in my case.

The problem is that these files are mounted from an old Solaris machine, and the context of everything loaded is system_u:object_r:nfs_t:s0. I need to modify just a handful of files that are mounted from that machine to httpd_sys_content_t.

Any attempt to do this, however, results in "Operation not supported". The command I am attempting to use is:

chcon -R -h -t httpd_sys_content_t /path/to/my/stuff

From what I can tell, this is because everything from that server is mounted as system_u:object_r:nfs_t:s0. Being Solaris, I can't go to the machine itself and use chcon, as SELinux and chcon don't exist.

The solution I can think of that will work is to just install the same software on this machine, which is RHEL6, cutting Solaris out all together. I'd like to know if that is my only choice or not.

share|improve this question

1 Answer 1

up vote 3 down vote accepted

Two options (within SELinux) exist:

1) All else fails audit2allow can convert any SELinux denials into allowed operation.

2) What I would recommend: Enable the SELinux boolean for allowing httpd_t to access nfs_t objects:

[root@ditirlns02 ~]# getsebool httpd_use_nfs
httpd_use_nfs --> off
[root@ditirlns02 ~]# setsebool -P httpd_use_nfs=1
[root@ditirlns02 ~]# getsebool httpd_use_nfs
httpd_use_nfs --> on
[root@ditirlns02 ~]# 

Security contexts are set by the machine that mounts the remote filesystem, so Solaris is largely unrelated. Even if the exports were coming from RHEL the NFS exports are still going to be nfs_t and there's not much you can do about that

share|improve this answer
    
Number 2 worked perfectly. Thanks. –  CptSupermrkt Nov 3 '13 at 23:42
    
Right, but why weren't you able to change the SELinux context? Maybe should've tried semanage fcontext -a -t httpd_sys_content_t /mounted/on/local/dir –  ILMostro_7 Nov 4 '13 at 5:03
    
I guess maybe the remote program would need access to resources/locations that were not already allowed to the httpd service. –  ILMostro_7 Nov 4 '13 at 5:10
    
File contexts are stored with inode information, in ext3/4 this is an "extended attribute". For network filesystems like AFS, NFS, SMBfs, etc there is no metadata to store individual file's context information. The best SELinux can do is segregate by network filesystem type. –  Bratchley Nov 4 '13 at 19:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.