[cups.development] [RFE] STR #2370: Provide a configure optionfor running the server as non-root

[Michael Sweet]

Martin Pitt wrote:
> Hi Mike,
> 
> Michael Sweet [2007-04-30  9:22 -0400]:
>> By running as an unprivileged user, you lose all Kerberos support,
> 
> I didn't use Kerberos so far, but that seems weird to me. Other
> services like PostgreSQL use Kerberos happily without *ever* running
> as root, and an authentication protocol which would only work as root
> would be really strange.

I don't know how PostgreSQL provides Kerberos authentication
without running as root.  The client side can do it, but the server
needs to be root or have some other authorization to get the user
credentials - otherwise it wouldn't be that secure, now would it?

*If* there is a way to allow cupsd to run as an unprivileged user
and still support Kerberos, I'll be happy to consider a patch.

>> LPD support,
> 
> -rwsr-xr-- 1 root lp 23724 2007-04-04 10:38 /usr/lib/cups/backend/lpd

Great, another setuid executable (which doesn't need to have world-
read, BTW...)

>> certificate support, 
> 
> Hm? Why you would need to be root just to read and write a file with a
> random number? Certificates work fine with the patch, and they have
> worked with 1.1 and RunAsUser in the past (with some bug fixes AFAIR,
> though).

When running non-root, certificate 0 becomes readable to all
processes running as that user, so (for example) all web pages would
authenticate to the "root" user and anybody could make changes on the
web interface.  I found this out the hard way early in the 1.3
development... :)

So, when not running as root, we disable the root certificate and
make people (even from the command-line) enter a password.

The SO_PEERCRED patches for 1.3 (STR #2242 and STR #2277) will
address the command-line authentication issue, at least on some
platforms...

We might also be able to play with running cupsd with multiple
groups (e.g. lp + the system groups), and then just make the
root certificate only group-readable.  That interface is at least
required by POSIX...

>> and proxy authentication support.  
> 
> I did not try this out yet, but passing authentication credentials
> around does not sound like needing any root privileges (squid runs the
> main stuff as normal system user as well). Can you explain that in
> more detail, please?

When not running as root, we disable the auth caching because
otherwise any print filter could read the information.  We don't
trust print filters...

Again, if cupsd used multiple groups, then we could make the
auth cache info only available to backends running in the
"privileged" group.

>> CUPS *needs* to run as root. We will not add this patch.
> 
> I have yet to see a technical argument for that.
 > ...

I've given you several already.  Another I didn't mention is that
we can't reconfigure CUPS (e.g. update the cupsd.conf file and
restart) without stopping and starting the process.

Jeff Licquia proposed running a "supervisor" instance of cupsd as
root that forked a copy of itself that ran as lp.  On reload, the
child would exit and the supervisor would then fork a new instance
as needed.  There are some issues with that approach, but we could
make it work.

Apple uses their launchd service to manage cupsd instances - some
of the init/inetd replacements out there might be able to do
something similar...

....

I'm not opposed to changes in CUPS that would allow it to run as
non-root in a production environment without a serious loss of
functionality or security.  I just haven't seen a valid patch or
proposal that gets us there (yet).

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com