Description of problem: I've just test tested webdav in enforcing mode on Fedora Devel and it doesn't work : - apache needs rw access on /srv (don't know where the default dav root should be, I put it in srv since its seems the FHS wants this kind of stuff there) type=AVC msg=audit(1130749513.951:3772): avc: denied { read } for pid=11759 comm="httpd" name="nim" dev=dm-0 ino=1048598 scontext=root:system_r:httpd_t:s0 tcontext=root:object_r:var_t:s0 tclass=dir type=SYSCALL msg=audit(1130749513.951:3772): arch=c000003e syscall=2 success=no exit=-13 a0=5555558ca410 a1=10800 a2=5555558c7ff8 a3=5555558c58a7 items=1 pid=11759 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" - it also needs rw acces to its default /var/lib/dav/lockdb.dir type=AVC msg=audit(1130749738.930:3777): avc: denied { write } for pid=11766 comm="httpd" name="lockdb.dir" dev=dm-0 ino=2392524 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1130749738.930:3777): arch=c000003e syscall=2 success=no exit=-13 a0=5555558c7580 a1=42 a2=1b6 a3=3 items=1 pid=11766 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=CWD msg=audit(1130749738.930:3777): cwd="/" type=PATH msg=audit(1130749738.930:3777): item=0 name="/var/lib/dav/lockdb.dir" flags=310 inode=2392223 dev=fd:00 mode=040700 ouid=48 ogid=48 rdev=00:00 Version-Release number of selected component (if applicable): selinux-policy-targeted-1.27.2-10 libselinux-1.27.17-1 httpd-2.0.54-14 How reproducible: Always Steps to Reproduce: 1.Create a webdav root in /srv 2.Try to use it in enforcing mode server-side Actual results: 1. Webdav clients fail when trying to manipulate the share 2. Various errors in apache logs : [Mon Oct 31 10:05:13 2005] [error] [client x.x.x.x] Provider encountered an error while streaming a multistatus PROPFIND response. [404, #0] [Mon Oct 31 10:08:58 2005] [error] [client x.x.x.x] File does not exist: /srv/dav/nim/t752.sxw [Mon Oct 31 10:08:58 2005] [error] [client x.x.x.x] File does not exist: /srv/dav/nim/t752.sxw [Mon Oct 31 10:08:58 2005] [error] [client x.x.x.x] The locks could not be queried for verification against a possible "If:" header. [500, #0] [Mon Oct 31 10:08:58 2005] [error] [client x.x.x.x] Could not open the lock database. [500, #400] [Mon Oct 31 10:08:58 2005] [error] [client x.x.x.x] (13)Permission denied: Could not open property database. [500, #1] Expected results: A working dav share No errors in httpd logs Additional info: I've reported this on the selinux list, I just want to trace it there so it's fixed before FC5
Dav/Apache problem -> CCing Joe Orton
Looks like a policy issue, httpd_t should have read/write/file-creation access to /var/lib/dav/*
Yes, that's why I opened an selinux bug, but I thought it would be nice to have you there to confirm apache needs read/write/file-creation access to /var/lib/dav/* AND /srv (and if srv is a no-go where people are supposed to put their dav roots)
Joe, Daniel would like to know if Red Hat got a specific policy regarding DAV files in /srv (ie should the default policy allow read/write/file-creation for all /srv, just a subdir in /srv, or none at all). My reading of : http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM is that if you use DAV as a way to share data (not a way to update web sites, but a CIFS/FTP replacement) this data belongs in /srv. If Red Hat does not define a specific part of /srv devoted to DAV use I'd say make all srv accessible to apache in the default policy. OTOH it's certainly cleaner to compartimentize /srv (on my box dav is in /srv/dav). What are your thoughts on the question ?
I'd say it would be best to leave /srv labelling entirely to user policy.
:( This will force a lot of people to learn selinux instead of being mostly transparent. Are you sure ?
To create a DAV repos you already have to create a directory and set up the permissions correctly, it's never been an "it just works" thing. The fact that you have to label it too is just an extra step.
It just got a little less "just works" I'll just ask for the lock dir then
Fixed in policy version 1.27.2-12
I can confirm -> closing