libreport version: 2.0.8 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 3.1.6-1.fc16.i686 reason: SELinux is preventing /usr/bin/polipo from 'open' accesses on the file polipo. time: Thu 29 Dec 2011 03:39:44 PM PST description: :SELinux is preventing /usr/bin/polipo from 'open' accesses on the file polipo. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that polipo should be allowed open access on the polipo file by default. :Then you should report this as a bug. :You can generate a local policy module to allow this access. :Do :allow this access for now by executing: :# grep polipo /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:polipo_t:s0 :Target Context unconfined_u:object_r:var_log_t:s0 :Target Objects polipo [ file ] :Source polipo :Source Path /usr/bin/polipo :Port <Unknown> :Host (removed) :Source RPM Packages polipo-1.0.4.1-4.fc16 :Target RPM Packages :Policy RPM selinux-policy-3.10.0-67.fc16 :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.1.6-1.fc16.i686 #1 : SMP Wed Dec 21 23:18:01 UTC 2011 i686 i686 :Alert Count 1 :First Seen Thu 29 Dec 2011 03:39:00 PM PST :Last Seen Thu 29 Dec 2011 03:39:00 PM PST :Local ID 8dbcb6cb-bad7-495f-a536-6c45c859a5ce : :Raw Audit Messages :type=AVC msg=audit(1325201940.475:167): avc: denied { open } for pid=5525 comm="polipo" name="polipo" dev=sda4 ino=3882 scontext=system_u:system_r:polipo_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file : : :type=SYSCALL msg=audit(1325201940.475:167): arch=i386 syscall=open success=yes exit=ESRCH a0=8b381ba a1=441 a2=1b6 a3=0 items=0 ppid=5524 pid=5525 auid=4294967295 uid=992 gid=990 euid=992 suid=992 fsuid=992 egid=990 sgid=990 fsgid=990 tty=(none) ses=4294967295 comm=polipo exe=/usr/bin/polipo subj=system_u:system_r:polipo_t:s0 key=(null) : :Hash: polipo,polipo_t,var_log_t,file,open : :audit2allow : :#============= polipo_t ============== :allow polipo_t var_log_t:file open; : :audit2allow -R : :#============= polipo_t ============== :allow polipo_t var_log_t:file open; :
restorecon -R -v /var/log/polipo* Is this log file being created within the init script?
No it is created by polipo but polipo(uid/gid) is not allowed to create it in /var/log/ (root:root) type=AVC msg=audit(1331826496.614:763): avc: denied { open } for pid=17587 comm="polipo" name="polipo" dev=dm-2 ino=2097381 scontext=system_u:system_r:polipo_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=AVC msg=audit(1331826496.614:763): avc: denied { create } for pid=17587 comm="polipo" name="polipo" scontext=system_u:system_r:polipo_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=AVC msg=audit(1331826496.614:763): avc: denied { add_name } for pid=17587 comm="polipo" name="polipo" scontext=system_u:system_r:polipo_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir type=AVC msg=audit(1331826496.614:763): avc: denied { write } for pid=17587 comm="polipo" name="log" dev=dm-2 ino=2098451 scontext=system_u:system_r:polipo_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir This is a bug in polipo Also logrotate creates it: # grep create /etc/logrotate.d/polipo create 0640 polipo polipo Same issue will probably apply to /var/cache/polipo
well /var/cache/polipo is installed by the package so it doesnt apply there
I just checked in fixes to allow polipo to create its own log file, cache dir, and pid file, added systemctl support, and allowed networkmanager to manage the service. to F17 policy. Needs to be back ported to F16.
That is not going to solve this issue. instead you may want to allow logrotate to create /var/log/polipo with a named file transition to polipo_log_t
I think logrotate already has selinux built into it. So it should label the file correctly at creation time
ok, well ive mentioned this before to polipo maintainer and the issue described above is related to the transition from the old way of managing the log to the current way. https://bugzilla.redhat.com/show_bug.cgi?id=741779 issue now is though that from a DAC perspective uid polipo is not allowed to create files in /var/log which is only writable by root. i asked him to just install a log file to get around this but instead he came up with this.
Although logrotate may only be maintaining the label. Does logrotate create the file if it never existed?
seems it does not, no it tried it with; [root@x220 log]# cd /var/log; ls -alZ polipo ls: cannot access polipo: No such file or directory [root@x220 log]# logrotate -f /etc/logrotate.d/polipo [root@x220 log]# cd /var/log; ls -alZ polipo ls: cannot access polipo: No such file or directory this issue is probably due to the transition of how polipo handles the log file creation. before the init script created it (with wrong label) now polipo itself tries to create it (which it cannot due to DAC issues)
Best solution would be to create a directory like httpd does and put your logs there. /var/log/polipo/polipo.log And have the dir owned by polipo
(In reply to comment #10) > Best solution would be to create a directory like httpd does and put your logs > there. > > /var/log/polipo/polipo.log > > And have the dir owned by polipo I would tend to agree at this point.
polipo-1.0.4.1-9.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/polipo-1.0.4.1-9.fc18
Package polipo-1.0.4.1-9.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing polipo-1.0.4.1-9.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-19595/polipo-1.0.4.1-9.fc18 then log in and leave karma (feedback).
polipo-1.0.4.1-9.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.