AW: [Desktop_printing] Role of CUPS and error handling

Michael Sweet mike at
Mon Mar 27 07:09:35 PST 2006

Johannes Meixner wrote:
> Hello,
> On Mar 24 18:05 Kurt Pfeifle wrote (shortened):
>> My point is: We need to make it much, much, much more easy for
>> users to find out why their current action fails, if they deal
>> with a cupsd running as non-root. They need to be guided to a
>> way how to resolve this.
> Agreed!
> Perhaps it would have been better when cupsd shows a more
> meaningful message when login to its web-interface fails.
> At the moment cupsd (CUPS 1.1.23) simply re-displays the
> login popup which lets most users think that there was a typo
> in what they entered and many users do endless re-tries.

Unfortunately, that is the nature of HTTP authentication in
browsers - there isn't much instruction we can provide the
user in the password dialog.

If the user hits "cancel", then they now get a slightly more
useful help message for the 401 unauthorized error, assuming
that the browser doesn't hide it that is... :(

> Of course such a meaningful message cannot reveal too much
> like "the second character of your pasword is wrong" ;-)
> Seriously: Even revealing the authentication method might
> be problematic regarding security (or would this be only
> security by obscurity)?

Security by obscurity: the HTTP authentication method is part
of the challenge sent to the client, and then for Basic
authentication there is PAM in the background...

> By the way:
> What looks a bit strange from my point of view with the discussion
> about RunAsUser is:
> When it is enabled, it is in compliance how CUPS 1.1.x can work.
> But the discussion seems to be as if we did something which
> is totally against how CUPS is designed to work.
> Perhaps this is even true because RunAsUser is no longer
> supported in CUPS 1.2?

The main issue is that, out of the box, SuSE's web interface can't
work because there is no lppasswd set.  That is the #1 question on
our CUPS forums (thus the prominent place on the CUPS home page...)

There are separate issues WRT RunAsUser, which I have explained in
other postings, which make it less secure than just running as

> On the other hand we really did something which is different
> than the original CUPS 1.1.x: Our "preauth_security" patch,
> see "Generalized Functionality for BrowseAllow and BrowseDeny" in
> I expected several complaints and problems here (in particular
> because one cannot switch off the "preauth_security" patch)
> but here everything is quiet.

Probably because those changes are less likely to cause problems
for a typical environment.  However, requiring someone to use
"BrowseAllow foo" to allow connections from "foo" is not intuitive,
so I'll bet there are some enterprise-class users that are not
able to use the SuSE CUPS packages because of this...

> ...
> There must be something very basic regarding usability which doesn't
> work when some of our users do such strange things.
> Personally I have the vague feeling that this users are
> neither unexperienced home-usres (those simply use YaST)
> nor experienced administrators (those read documentation
> or know how to ask for support) but something in between.

While I'm not generally one to quote ESR's ramblings, in his CUPS
diatribe he *did* make a good point: users shouldn't have to read
documentation to do "normal" things.  If you are going to ask the
user for a password, tell them what they need to enter, etc.

We've incorporated a lot of changes in the web interface based on
his (and others!) feedback, and in particular we have provided an
on-line help interface that we will be encouraging you guys to
use so that users have a common place to look for CUPS-related
documentation, in particular changes to the default configuration!

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software

More information about the Printing-summit mailing list