Bug 1127301

Summary:	subversion - it would be great to have subversion covered
Product:	Red Hat Enterprise Linux 6	Reporter:	lejeczek <peljasz>
Component:	selinux-policy	Assignee:	Lukas Vrabec <lvrabec>
Status:	CLOSED WONTFIX	QA Contact:	Milos Malik <mmalik>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.5	CC:	dwalsh, mgrepl, mmalik, peljasz
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-02 13:30:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description lejeczek 2014-08-06 15:05:38 UTC

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):
selinux-policy-3.7.19-231.el6_5.1.noarch
selinux-policy-doc-3.7.19-231.el6_5.1.noarch
selinux-policy-targeted-3.7.19-231.el6_5.1.noarch


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 lejeczek 2014-08-07 08:06:19 UTC

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?

Comment 3 Daniel Walsh 2014-08-07 12:49:13 UTC

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.

Comment 4 Miroslav Grepl 2014-09-04 09:56:29 UTC

Did you run restorecon on it?

Comment 5 lejeczek 2014-09-04 13:41:06 UTC

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

Comment 6 Miroslav Grepl 2014-09-05 09:59:19 UTC

What are full paths?

Comment 7 lejeczek 2014-09-05 12:27:10 UTC

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

Comment 8 Miroslav Grepl 2015-03-02 13:30:50 UTC

I believe we can go with a local modifications here. If we get it working, we will reopen the bug for RHEL7/Fedora.