Sorry for commiting this again, but there has been no response from any of the developers on #7163 for over 3 months and it didn't appear in portage. I guess another person is now responsible for privoxy. This ebuild bumps the version to 3.0.0 and fixes some bugs, especially that one that made privoxy not running as privoxy.privoxy but as root.root.
Created attachment 6333 [details] Privoxy 3.0.0 ebuild
*** Bug 7163 has been marked as a duplicate of this bug. ***
Hi Seamant, actually this bug is a duplicate of (#7163). And BTW are there any reasons, why since privoxy 2.9.14_beta every of my comitted privoxy ebuilds was not commented neither committed to the portage tree by gentoo officials? Hi Fridtjof, I didn't answer your comment beause I was really busy at this time and I only read "gentoo developers", and I thought I wasn't mean with this, beacuse I am not an official gentoo dev. And for the reasons why it is not committed since so long time (and not even as ~86) I really don't know. I have committed several ebuilds for privoxy versions > 2.9.14 (includining the initial 2.4.19_beta) and haven't get any comment from official devs (see above). Regards
Permissions on /etc/privoxy are incorrect (and quite possibly on other files too). They are installed as owned by "privoxy.privoxy". This is a *HUGE* security risk, since the configuration specifies log files, etc. and privoxy only changes uid *AFTER* having read the configuration file. This enables any user which compromises the "privoxy" user/group (or the daemon itself) to change the UID of the privoxy daemon to any other user (including root) simply by changing the configuration setting. This could quite possibly also be exploited to overwrite logfiles by using the "log file" configuration directives. My proposed solution: Change permissions on /etc/privoxy so that: - root owns the directory, but "privoxy" group has read+execute. - root owns the config files. - privoxy.privoxy owns the rest of the config files (not absolutely sure, but if privoxy changes UID after reading the main config it should be safe). This will probably cause problems with the "live" editing of configurations that privoxy has built-in, but I think changing the permissions is the only reasonable thing in light of such a security risk. A way around the live editing thing would be to create a sub-directory within /etc/privoxy, where all the editable files reside and which could safely be set to being owned by "privoxy". I haven't got the time to do this, but it would probably solve these problems once and for all.
I'll take care of this one myself.
added to portage.
added to portage
