Description of problem: selinux is preventing abrt to use inotify on /var/spool/abrt-upload directory. Version-Release number of selected component (if applicable): current policies in Fedora 16, 17 How reproducible: Always Steps to Reproduce: 1. echo "WatchCrashdumpArchiveDir = /var/spool/abrt-upload/" > /etc/abrt/abrt.conf 2. service abrtd restart Additional info: ---- time->Mon Jul 2 13:18:14 2012 type=SYSCALL msg=audit(1341227894.585:190): arch=c000003e syscall=254 success=no exit=-13 a0=5 a1=c4b4a0 a2=88 a3=7fff57ccb040 items=0 ppid=1 pid=5927 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe="/usr/sbin/abrtd" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1341227894.585:190): avc: denied { read } for pid=5927 comm="abrtd" name="abrt-upload" dev="vda2" ino=13508 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir ---- time->Mon Jul 2 13:18:23 2012 type=SYSCALL msg=audit(1341227903.633:193): arch=c000003e syscall=2 success=no exit=-13 a0=404077 a1=41 a2=1a4 a3=7fff38afd020 items=0 ppid=1 pid=6019 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe="/usr/sbin/abrtd" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1341227903.633:193): avc: denied { write } for pid=6019 comm="abrtd" name="abrtd.pid" dev="tmpfs" ino=26672 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_run_t:s0 tclass=file
Second avc is related to abrtd.pid: Jul 2 13:42:09 localhost abrtd: Can't open '/var/run/abrtd.pid': Permission denied Jul 2 13:42:09 localhost abrtd: Error while initializing daemon Jul 2 13:42:09 localhost abrtd: Exiting
If you use this directory, you need to turn on the abrt_anon_write boolean # setsebool -P abrt_anon_write 1 The second AVC is really strange. # restorecon -R -v /var/run/abrt* and see if you can re-create it.
/var/spool/abrt-upload/ is our default directory for handling uploads (owned by abrt package) - would be better if access is allowed by default. Or is there any reason why abrt isn't allowed to watch this directory? What we need is inotify watch and permission to delete (move) data from this directory to /var/spool/abrt/ dir.
We designed this directory to have this labeling because it can be used by different services.
We can simply document it in deployment guide, but it's not very user friendly.
The problem is this directory can be used by ftpd_t for example. So this is a reason why we added this labeling (together with Karel).
Does it only read from this directory or does it also write? It should be allowed to read from the directory by default.
I believe it also write. But ABRT folks please correct me if I am wrong.
Both, but if we can have at least read and inotify on that dir it would give us at least the basic functionality. Forbidden write means that we won't be able to remove the uploaded data from abrt-upload directory, but it's not critical for ABRT to process it (we can copy it and process is elsewhere).
Yeap, I am adding "read" by default.
Is this just a directory that ftp and dovecot share or would other apps like httpd need access?
Any application which knows the right format can upload the problem_dir there, but the only actually existing use case are ftpd, scp and cp (for tests).
I am not looking at theoretical, just real world. If ftpd is the only domain that we confine that can write to this directory then we should label it as abrt_upload_t and allow ftpd_t and abrt_t to write to it.
All of them are real world - scp is in my opinion more important than ftpd.
selinux-policy-3.10.0-140.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-140.fc17
Package selinux-policy-3.10.0-140.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-140.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10840/selinux-policy-3.10.0-140.fc17 then log in and leave karma (feedback).
selinux-policy-3.10.0-140.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.