Description of problem: If i open http://www.netscape.com privoxy tries to connect to port 9000. SELinux prevents this. I'm not sure if this is expected behaviour of privoxy. It sure looks fishy to me. avc: denied { name_connect } for comm="privoxy" dest=9000 egid=73 euid=73 exe="/usr/sbin/privoxy" exit=-13 fsgid=73 fsuid=73 gid=73 items=0 pid=10260 scontext=user_u:system_r:privoxy_t:s0 sgid=73 subj=user_u:system_r:privoxy_t:s0 suid=73 tclass=tcp_socket tcontext=system_u:object_r:port_t:s0 tty=(none) uid=73 Version-Release number of selected component (if applicable): 2.6.4-48.fc7 How reproducible: Currently always, but only for http://www.netscape.com Steps to Reproduce: 1. configure firefox to use privoxy 2. goto http://www.netscape.com 3.
Is this something privoxy should be doing?
Not unless you've reconfigured privoxy to use port 9000 instead of the default port 8118. Have a look at /etc/privoxy/config and search for listen-address to verify.
For the record. My privoxy is configured to use port 8118 in /etc/privoxy/config.
Perhaps i made this not clear enough. I'm using privoxy permanently while surfing the web. It only tries to connect to port 9000 if i visit http://www.netscape.com. I can still reproduce this.
I can't reproduce this. Have you configured privoxy to replace http://eatps.web.aol.com with localhost or modified /etc/hosts for the same effect ? Does a grep for '9000' in /etc/privoxy show anything ? Daniel: Would an privoxy access to http://localhost:9000 cause the reported error ?
> Does a grep for '9000' in /etc/privoxy show anything ? No nothing. Judging from the timestamps all configuration files are unchanged from the initial installation. user.action has a newer timestamp, but only a few rules that look normal to me. > I can't reproduce this. Have you configured privoxy to replace > http://eatps.web.aol.com with localhost or modified /etc/hosts for the same > effect ? No. Privoxy config is unchanged and /etc/hosts contains nothing special.
Yes this means privoxy tried to connect to port 9000. Could this be the cause? http://www.panix.com/help/proxy.html
Sorry for my response being a little late. But i cannot see how the above post is relevant to this topic. I do not use ssh forwarding an i do not use the services of panix.com. The only instance port 9000 is mentioned in the panix documentation is with the ssh setup. I'm not quite sure, but privoxy tries to bind to the port 9000 not to connect to the port. At least this is what i get from the troubleshoot message: SELinux has denied the /usr/sbin/privoxy from connecting to a network port 9000 which does not have an SELinux type associated with it. If /usr/sbin/privoxy is supposed to be allowed to connect on this port, you can use the semanage command to add this port to a port type that privoxy_t can connect to. semanage port -L will list all port types. Please file a bug report against the selinux-policy package. If /usr/sbin/privoxy is not supposed to bind to this port, this could signal a intrusion attempt.
The avc says that privoxy attempted to name_connect (connect function call in C) to port 9000.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.