Description of problem: The recent tests show lots of ACV denials from user httpd on the F13 i386 system during work of SW nightly. Version-Release number of selected component (if applicable): SW-nightly (20100-09-17) How reproducible: through rhts test Steps to Reproduce: 1. install SW nightly on F13 2. make some actions (like rhnpush a package and try to remove it through API) 3. look for AVC denials for the user httpd (/usr/bin/env LC_ALL=en_US.UTF-8 /sbin/ausearch -sv no -m AVC -m USER_AVC -m SELINUX_ERR) Actual results: time->Sat Sep 18 00:27:00 2010 type=SYSCALL msg=audit(1284784020.343:32455): arch=c000003e syscall=4 success=no exit=-13 a0=7fc65c00af60 a1=7fc663ffca10 a2=7fc663ffca10 a3=2f746f6f62657870 items=0 ppid=1 pid=5715 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cobblerd" exe="/usr/bin/python" subj=system_u:system_r:cobblerd_t:s0 key=(null) type=AVC msg=audit(1284784020.343:32455): avc: denied { search } for pid=5715 comm="cobblerd" name="satellite" dev=dm-0 ino=1582093 scontext=system_u:system_r:cobblerd_t:s0 tcontext=system_u:object_r:spacewalk_data_t:s0 tclass=dir ---- time->Sat Sep 18 00:27:00 2010 type=SYSCALL msg=audit(1284784020.343:32456): arch=c000003e syscall=4 success=no exit=-13 a0=7fc65c00af60 a1=7fc663ffca10 a2=7fc663ffca10 a3=2f746f6f62657870 items=0 ppid=1 pid=5715 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cobblerd" exe="/usr/bin/python" subj=system_u:system_r:cobblerd_t:s0 key=(null) type=AVC msg=audit(1284784020.343:32456): avc: denied { search } for pid=5715 comm="cobblerd" name="satellite" dev=dm-0 ino=1582093 scontext=system_u:system_r:cobblerd_t:s0 tcontext=system_u:object_r:spacewalk_data_t:s0 tclass=dir Expected results: no avc denials Additional info: This bug is very simmilar to bug 631750, which was affecting httpd on Fedora-13
I found that there is new boolean on fedora-13 only, which allows you doing it setsebool -P cobbler_anon_write on shouldn't be this boolean setup automatically at time of spacewalk installation ?
Mass-moving to space13.
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Aligning under space16.
This bug has been fixed in Spacewalk 1.5 by commit 121140517b765134eeb56caff84fdbb88247ccf3 702274 - allow cobblerd_t to read spacewalk_data_t