AW: [Desktop_printing] Role of CUPS and error handling

Johannes Meixner jsmeix at
Fri Mar 24 07:01:17 PST 2006


On Mar 24 14:17 Kurt Pfeifle wrote (shortened):
> On Friday 24 March 2006 12:26, Johannes Meixner wrote:
> > Do you mean the problems when cupsd runs as lp?
> > If yes, please read
> >
> > it is all explained there in detail.
> That's fine with *me*, and probably with most people on this list.
> But it is not good and *easy* enough for most Aunt Tillie users...
> Are you sure that all users who encounter a problem that stems from
> SUSE's "RunAsUser" setting are immediately pointed to that website?
> Are you also sure they follow the link? Are you sure they read it?
> Are you sure they understand it?

The answers are: No, no, no, no.

We know very well all (hopefully all) the drawbacks
when cupsd runs without unlimited privilleges.

Not only the drawbacks about anything which does no longer work
when cupsd runs without unlimited privilleges but also the
drawbacks when cupsd, filters and backends run as the same user.

Obviously any service just works well out of the box when
the service has unlimited privilleges - it is the nice warm
Windows like feeling that "everything" just works out of the box.
With "everything" I mean "everything", really "everything",
in particular "everything" from "everywhere" ;-)

Obviously unlimited privilleges is not in general a good
solution to get something just work out of the box.

If it is good or not to run cupsd by default with unlimited
privilleges is and was discussed in deep detail.
We decided not to run cupsd by default with unlimited privilleges.
In CUPS 1.2 "RunAsUser" is gone and the discussion may start again.

> > Note that it is about a general company security policy
> > and not about what a few printing guys may think.
> That's what the company security politicians think; and what maybe
> you and I think too.
> But what do your *users* think? "F*#ck! SUSE is too secure to let me
> simply print!?!"

I know that some of our users may think this.

On the other hand:

Only CUPS web-admin access fails without "lppasswd".
The rest of the CUPS web frontend works.
YaST or "lpadmin" do not need any "lppasswd" because any
printing admin tool which runs as root on localhost works
without any "lppasswd" command.
Unfortunately some printing admin tools (KDE or Gnome or both,
it has changed and I do not remember exactly) do not run by default
as root on localhost but do CUPS authentication by default 
even if the tool is used to talk to the cupsd on localhost.
Our manual only describes to use YaST or lpadmin to set up queues
and it describes the "cupsd runs as lp" stuff and the "lppasswd".
Obviously the "F*#ck! SUSE" users try to use a admin tool which
fails and then they don't even try to use YaST or read our manuals
or use our support database but complain to the public ;-)

We do care about our users (perhaps we don't care about
"F*#ck! SUSE" users) but we do care about our users.

In particular we care about the security of the hundreds of
thousands of systems which are administrated by unexperienced
users and which are exposed to "everything" from the Internet.

Threfore we think that a service must not run by default
with unlimited privilleges when it doesn't really need
unlimited privilleges.

For strictly RFC 1179 compliant LPDs the source port must
be <1024 for which the lpd backend has to run as root (*)
but this is not a sufficient reason form our point of view
to let cupsd run with unlimited privilleges by default
on any system.

It is another (but related) question whether it is a good idea
to run filters and backends and the cupsd as the same user.

Please note my permantent "by default".
By default our cupsd does not run with unlimited privilleges
and our default admin tool works well with it
and printing also works well with it (except *).
An uneperienced user does not need to know anything about
our defaults.
If an experienced user does not like it, it is well described
what he can do.

Kind Regards
Johannes Meixner
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at
90409 Nuernberg, Germany                    WWW:

More information about the Printing-summit mailing list