Bugzilla Bug 11835

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 an attachment (id=6333) [edit]
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