[cups] Running CUPS backends (e.g., IPP) as non-root

Michael Sweet msweet at apple.com
Tue Feb 16 15:18:38 PST 2016


Brian,

> On Feb 16, 2016, at 3:02 PM, Brian Norris <computersforpeace at gmail.com> wrote:
>> ...
>> In the case of the IPP backend, it is not about privileged ports but
>> of having access to user credentials as root.
> 
> So, if I don't need Kerberos, IPP doesn't actually need to run as root?

Correct.

>> Recent versions of CUPS (since 2.0) support the backend with group
>> read/execute
> 
> So chmod 750 /usr/libexec/cups/backend/ipp is "supported"? From the
> code, it looks like it gracefully degrades when run as a non-root user.

We don't officially provide support, but it should work just fine for anything except Kerberos...

>> (just not world read/execute).
> 
> Why would world read/execute be relevant? Or, why does the fact that
> other users can read/execute the binary have anything to do with what
> the program behavior should be? I've never actually seen a program care
> what other users can do with its executables.

That is how we decided to differentiate between backends that should run as root vs. those that should run as lp. The advantage is that a) there isn't a separate configuration file that can break and b) backends that need to run as root probably cannot be used successfully as an ordinary user anyways.

(there *is* precedent for things like the ~/.ssh directory, which must not be world-readable, and for other software that installs with restricted permissions to prevent execution by ordinary users...)

>>> I realize I could hack around this myself in various ways (e.g, 'chmod
>>> 755 /usr/libexec/cups/backend/foo'), but I wanted to see if you were
>>> considering alternatives to this permissions-based check. For instance,
>>> instead of saying "Backends are run either as a non-privileged user or
>>> as root if the file permissions do not allow user or group execution"
>>> [1], we could instead make this configurable (e.g., in cupsd.conf).
>> 
>> That itself would open up a security hole;
> 
> What is "that"?

Putting a configuration directive in cupsd.conf that allowed backends to run as root without being owned by root and with the restricted permissions.  (we moved all of those kinds of things to cups-files.conf a year or two ago to address a security vulnerability that Google discovered)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer




More information about the cups mailing list