Michael Sweet mike at
Thu Jul 29 21:25:02 PDT 2004

Troels Arvin wrote:
> On Thu, 29 Jul 2004 10:01:36 -0400, Michael Sweet wrote:
>>>I want to run cupsd as a non-root user to minimize the impact if a 
>>>security hole is found in Cups.
>>First, RTFM.
> Oops, sorry. I must have missed that when I read the administrator manual
> some years ago.
>>     1. All filters and backends have write access to the
>>        configuration files in /etc/cups, spool files in
>>        /var/spool/cups, and log files in /var/log/cups,
> I don't quite get this. Is your point, that even if cups is run as a
> non-root user, then the filters/backends might still be broken if a
> potential hole is exploited?

Yes; the scope of the exploit would, of course, be limited, but
I am just pointing out that running as a non-root user doesn't
provide complete safety.

>>     2. The LPD backend is unable to reserve a priviledged port,
>>        which disables printing to some LPD printers and print
>>        servers,
>>     3. You have to provide write access for the "lp" user and/or
>>        "sys" group to all parallel, USB, serial, and SCSI devices
>>        that you use.  This may open additional security holes.
> I could live with that.
>>     4. The scheduler (cupsd) cannot be restarted without killing
>>        the process and starting it again if you listen on a
>>        priviledged port like the default port 631; this means that
>>        SIGHUP and remote updates of cupsd.conf will not work,
>>        resulting in more down time when you make configuration
>>        changes.
> OK. I sometimes use a dirty trick for situations like this: Bind the
> daemon to an unprivilidged port outside the dynamically allocated port
> areas (could be port 2000 as an example) and then use iptables to forward
> trafic from the well known (priviliged) port.
>>In the future, we hope to leverage the selinux stuff to provide
>>the best of both worlds: don't run as root, but still be able
>>to change to other users (perhaps "lpfilter" and "lpbackend")
>>and reserve priviledged ports so that you don't lose the
>>functionality and don't open yourself up to additional exploits
>>when using "RunAsUser" or its successor.
> Sounds interesting. Until then: Have you looked into the "capability"
> system?
> (I believe that BIND uses those, for example.)

I haven't looked into this, mainly because I've not heard of this
interface on Linux before and it doesn't appear to be implemented

Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX             

More information about the cups mailing list