[cups.general] Q. Proper way to startup cupsd as a non-root user asopposed to debian hacks?

[wtautz]

Michael Sweet wrote:

> wtautz wrote:
>
>> 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.
>
>
> 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....
>
>
> 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.  

Ok. Didn't know that.

> 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.
>
Yes. Number 5 is a problem for me. This is why I gave up on ubuntu for
the server. Thanks for
the other info. I guess the real issue is security in general, i.e., we
must have
some process running as root and assuming there aren't any outright bugs
in that process one should use some kind of external tool to provide further
security. Perhaps a chroot?
Or SeLinux?
 

> You are also leaving yourself open to filter-based attacks because
> of the loss of privilege separation.
>