Deny/Allow override in Location

Michael Sweet mike at easysw.com
Mon Nov 28 14:00:40 PST 2005


Antti Harri wrote:
>> In the future, please report this sort of thing using the STR form
>> at:
>>
>>      http://www.cups.org/str.php
> 
> I didn't want to register for submitting just one bug report.
> It doesn't allow submitting without a login, does it?

No, we require a login so that we can contact you to ask for more
info, try a patch, etc. as needed.  We got a lot of noise/spam
before the login stuff was added... :(

> ...
> Sometimes one wants to disable the ability to make changes to the
> running system. I mean, what quarantees do you have that the user is
> privileged to view other people's print jobs just by having access to
> localhost? Such user can be legitimate user added by root or malicious
> attacker who has gained access to the system and can further exploit to
> system due this kind of behaviour in the printing system.

Normally you have authentication in place for sensitive areas such
as /admin.  That authentication prevents changes unless you can
prove you are an authorized user...

As for hiding other users' print jobs, CUPS does not do that and we
do not provide any guarantees or support for that.  Any user can see
any other user's print jobs, they just can't see the contents of
those jobs (i.e. the print files) unless they physically take the
output from the printer.

In short, you changes do not offer any added security but do make
it easier to have a non-working configuration.

> If someone wants to give all access from localhost that can be achieved
> by two ways: making sure there is 127.0.0.1 listed in Allow or by not
> having Deny/Allow at all. So I don't see any point for having that
> hard-coded in the code. The default configuration can reflect this
> behaviour so it will continue to work like it used to.

It will break existing installations which make the assumption that
localhost is always allowed.  CUPS has worked this way for 6+ years
and you are the first person to propose a change to that...

> It only 'breaks' commands that you want. For example lpq still works if
> one lists access to /jobs etc.

Except that all read-only operations may be issued to any resource
on the server (i.e. "/").  You aren't adding security by blocking
localhost.

> Consider a scenario where there is a server with two clients connected.
> All three computers have CUPS installed. Only the clients are supposed
> to send print jobs to the server which prints them. So there isn't
> any reason to allow access from localhost, because there isn't any need.
> For /jobs and /printers the admin lists those two clients. Like that
> one can print from the clients and delete jobs and so on. Everything
> that is required, at least in my point of view.

And how will you test that printing works when the clients are
down or not working for some reason?  How do you verify that the
server is still working?

Again, this is not a compelling reason to change the current
behavior.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com




More information about the cups-devel mailing list