Description of problem:
I struggle a bit on my httpd + subversion, pretty standard, I follow general guidance which says label with httpd_sys_content_t
I guess some dirs may need: httpd_sys_rw_content_t or/and httpd_sys_script_exec_t
I get denials about which audit2allow says: allow httpd_t file_t:dir search
my config uses pam for auth but I have:
allow_httpd_mod_auth_pam --> on
Version-Release number of selected component (if applicable):
Steps to Reproduce:
seems like file_t of the filesystem top of a device won't do
and then subsequent path to the svn repository also should not be file_t
what fcontext would be most suited?
file_t means there is no labels, probably a disk created on an SELinux Disabled system. you want to at least run restorecon on the content.
Did you run restorecon on it?
well, I just labelled the mount path to public_content_t
and for repository itself under/via apache
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 conf
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 dav
drwxrwsr-x+ root root system_u:object_r:httpd_sys_content_t:s0 db
-r--r--r--. root root system_u:object_r:httpd_sys_content_t:s0 format
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 hooks
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 locks
-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 README.txt
but what I was hoping for was that we would have selinux policy covered this, svnadmin create creates standard struct and is always predictable, could probably be better labelled for security than what I did
What are full paths?
full paths are not necessary standard/regular ones
mine are off the root and then a mounted device which is different from root mounted fs, eg.
/_.aLocalStore/somePaht/etc (some path is a top of a dev)
but I'd imagine subversion repos under httpd would/should per default go under /var/www somewhere
I believe we can go with a local modifications here. If we get it working, we will reopen the bug for RHEL7/Fedora.