Comment 13 for bug 47773

Ante Karamatić wrote:
> It's between "Rejected" and "Confirmed". For fixing this bug we should
> run cups as root or introduce setuid program.
>
> ** Changed in: cupsys (Ubuntu)
> Status: Needs Info => Confirmed
>
>
Hi, In a recent thread Michael Sweet outlined point by point
why not running as root breaks things. Of course, he is open
to patches.
> Michael, Does cups allow running as a non-root user? Obviously
> I know I could just start it up as a non-root user but that clearly
> implies it would have limited capabilities from the start.
>
> Most daemons that run as a non-root user usually start up
> as root and then exec a child with lesser priviledges *after*
> they checked things like permissions and the like.
Michael responds:

Actually, it is a crap shoot whether the daemon will do this
for you, however for CUPS we MUST run as root in order to do
many common things. As I covered in my presentation at the
Linux Printing Summit this year, running as an unprivileged
user is actually *less* secure with CUPS, as you lose the
privilege separation between scheduler and filters which have
a lot less auditing done on them...

> The debian boys have hardwired the userid cupsys into
> the code. It would be nice if there were a way to do this
> in a cleaner way using your original source. Perhaps a compile
> time define or perhaps the USER variable could be used to
> identify the userid that cupsd should run as? I know
> you've deprecated RunAsUser but....
Michael responds,

We aren't going to bring back RunAsUser. All of the Linux distros
already provide helper functions for their init scripts to run as
a different user, I suggest you look there if you really want to
cripple your CUPS install. You will also need to update the
/etc/services file on every system that wants to print with the
new port number for the IPP service...

FWIW, the following will not work if you don't run as root:

    1. Printing and browsing on port 631 (or any port < 1024)
    2. Automatic root authentication via certificates.
    3. Proxy authentication support (you'll need to hardcode
       usernames and passwords in your device URIs again).
    4. Local account authentication via PAM (although I've
       heard there is now a workaround for this by adding the
       user you run cupsd as to a PAM group)
    5. LPD printing support.
    6. Legacy client support via /etc/printcap and
       /etc/printers.conf. This kills printing from GNOME apps
       on Solaris 10, for example.
    7. (future) Kerberos support.

You are also leaving yourself open to filter-based attacks because
of the loss of privilege separation.
-------------------end of Michael and my exchange with him
--------------------

Me: Number 5 is relevant to this bug report.
-