FS#50544 - [privoxy] privoxy.service fixes & PKGBUILD changes

Attached to Project: Community Packages
Opened by I Said Socks (socks) - Sunday, 28 August 2016, 12:56 GMT
Last edited by Ivy Foster (escondida) - Thursday, 10 October 2019, 19:39 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Updated build scripts here:
https://gist.github.com/lolilolicon/1e2a78d453060b9a4cf83b0d094f136a

For privoxy.service, take a cue from tor.service:

* `--no-daemon` makes `Type=simple`.
* `--no-daemon` implies logging to journal.
* `User=` instead of `--user`: privoxy(1) needn't be run as root.

Install script:

* Use systemd-sysusers(8) to add user "privoxy".

PKGBUILD:

Since the `install` part of the upstream GNUMakefile is pretty much
broken for a packager, I've extracted what it actually means to do, and
write that directly in `package()`. Better than "oops! gotta add another
fixup again!" IMO.

Now about the permissions of the conf files. Currently, /etc/privoxy is
owned by privoxy:privoxy, and files under it is of permission 660. This
is so that these files are writable by privoxy, enabling for the user to
edit config files in the browser. This feature is by default turned off
(enable-edit-actions=0), and I don't think it's very useful or desirable.

So in my PKGBUILD, I make /etc/privoxy/* root:root. There is a reason
/etc/ is called sysconfdir; let's not make an exception for privoxy here.

Also I give /etc/privoxy/* permissions of 644, instead of 660 which with
root:root ownership forbids privoxy from reading them. The 0 bit of 660
didn't really make much sense, since local user can already read them in
the browser.

/var/log/privoxy/ is privoxy:privoxy for configured logfile, although
it's never written to with the new systemd service.



Additional info:
* package version(s): privoxy 3.0.24-3

This task depends upon

Closed by  Ivy Foster (escondida)
Thursday, 10 October 2019, 19:39 GMT
Reason for closing:  Implemented
Additional comments about closing:  All these ideas seem to have been implemented.

Loading...