[cups.bugs] incorrect permissions on dnssd and lpd

[Michael Sweet]

Johannes,

On Apr 13, 2012, at 1:19 AM, Johannes Meixner <jsmeix at suse.de> wrote:
> ...
>> Running the backend directly is definitely not supported.
>> CUPS provides an API for this (cupsGetDevices)...
> 
> Can you explain why it is not supported to run a CUPS backend directly?

Because we have changed the low-level interface to backends in pretty much every minor release of CUPS, and because these programs are designed to run in an environment separate from a user session and many simply will not work from the user session, either because of permissions or other issues.

> I neither see a reason for it in the documentation nor can I imagine
> what would fail in general if a CUPS backend is run directly.

We don't say "you can't run backends on your own", but we do say "this is how to write a program that acts like a CUPS backend".

Some backends are specifically designed to allow use outside of CUPS (like the SNMP backend), but most are *not* and will not behave correctly if run by the user.  Even our own internal test tool (testbackend) goes to great lengths to reproduce the environment and file descriptors setup by cupsd.

There are (unfortunately) way too many examples of misuse in the past, and every time I get a bug about "foo backend does not work when I run it directly" I give my "don't do this" speech and close the bug as not to be fixed.

Just as for the configuration files, the location and format of job control and data files, etc., how we run backends is an internal implementation detail and not a supported path for users to do stuff behind CUPS' back.

> In particular I think that it should work when the same CUPS backend
> is run reveral times simultaneously (e.g. when there are several
> print queues for the same printer device and all do active printing)
> then the backend should do "the right thing" what is needed for
> mutual exclusion for the particular case of the particular backend.

The problem isn't a matter of mutual exclusion.

> ...
> This seems to indicate that any user is allowed to run the UBACKENDS
> directly as he likes.

Fine, I'll document prominently that you don't run backends (or filters) directly.

The only difference in the makefile is whether the backend is installed with restricted permissions which tells cupsd to run the backend as "root" or normal permissions which tells cupsd to run the backend as "lp" (or whatever unprivileged user account is assigned on the system).  THIS HAS BEEN DOCUMENTED SINCE CUPS 1.2.

NOWHERE do we say that backends are normal user programs, and given that they are installed in /usr/{lib|libexec}/cups/backend I would expect developers to have a clue that they should not be treated the same as programs in {/|/usr|/usr/local}/{bin|sbin}.  The only time you might run a backend or filter directly is for testing/debugging, and then only with the correct guidance for which environment variables and file descriptors need to be setup for a particular filter or backend.  THEY ARE NOT NORMAL USER PROGRAMS - we put those in the usual place where the user's execution path will find them.

Do you advocate users run the GCC component programs under /usr/{lib|libexec}/gcc?  Or do you rightly point them at the user programs in /usr/bin?  The same applies to CUPS.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair