cupspykota should drop privileges

[sle]

In [3276], cupspykota was changed to no longer drop elevated privileges because the process provided no actual security benefit. While that reasoning is somewhat valid, cupspykota should continue to drop privileges because pykotadmin.conf may be stored in a location that is inaccessible to users with elevated privileges (e.g. root).

Sample scenario: PyKota's configuration file is stored in ~pykota/pykotadmin.conf. It is common for large organizations to place home directories on NFS shares with root-squash enabled. Thus, if cupsykota does not drop its privileges, it will be unable to read pykotadmin.conf.

[jerome]

I won't change this for several reasons. First it's easy to ensure cupspykota doesn't run as root at all : simply do chmod 755 cupspykota, so there's no need to drop privileges. Then of course some backends may not be supported anymore by cupspykota (like lpd}}, which requires to locally open {{{TCP/515 I think) but this is a tradeoff, most other backends, in particular ipp and socket, should work just as well. The second reason is that users created specially for a particular application usually are not created with an NFS home directory : you probably wouldn't do this for PostgreSQL's postgres user for example, otherwise by default databases would be NFS hosted. So moving ~pykota outside of NFS would solve your problem. Finally this complexifies the code a lot, and I'd like for 1.27 to be simpler than previous releases.

[sle]

It does not matter if cupspykota is executable by users other than root; it will still be run as root because CUPS is designed to run as root (otherwise it would be impossible for CUPS to listen on port 631). As far as I can tell, CUPS does not drop privileges after opening a privileged port, which Apache does for example.

PyKota's home directory will be NFS-hosted if you want PyKota's tools to be accessible on different machines without storing a copy of the configuration on every machine.

The code complexity can be solved by using a wrapper function for any system or shell calls: the wrapper function can decide whether or not elevated privileges are necessary for a command, and any future changes to the privilege handling code would only have to be made in a single place. This would go help you achieve your goal of simplifying the code.

[jerome]

To the best of my knowledge, CUPS v1.3.x and higher, maybe even 1.2.x, never runs a backend as root unless both the following conditions are met :
* The backend is owned by root.root
* The backend is chmod 0700

In the general case, the backends are run as an unpriviledged user, like lp for example.

[sle]

Thanks for the help and information. I got CUPS to run cupspykota as an unprivileged user, resolving this issie.

However, you'll definitely need to use permissions less restrictive than 700. I had cupspykota owned as lprng:root with 700 permissions, and it still was executed as root. It only was executed as lprng once I changed the permissions to 750.

Perhaps cupsykota can output a warning if it detects that it is running as root?