[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Password checking API
From:       Michael Goffioul <goffioul () imec ! be>
Date:       2001-10-03 13:08:38
[Download RAW message or body]

> Does this mean that cupsd allows anyone to spoof print jobs for any other user
> without giving a password??? In that case I wonder, why lprm keeps asking me
> for user name _and_ password everytime (somehow I need to enter "root" and
> the root password to remove jobs even if they are mine). That made me think
> the server authenticated me via that password. So, does only lprm check the
> pw and send a request to cupsd if it's correct?
> 
> Can one effectively do something to the effect of (I don't know IPP, so just a
> mockup protocol):
> 
> telnet printserver 631
> <= CUPS server here, hi there
> => Malory here, user name is "root"
> <= Hi, nice to meet you
> => Delete all jobs
> <= Ok, done, bye

OK, I'll clarify a little bit here. The whole thing depends on how you setup
security on CUPS server. As you maybe know, CUPS has access restriction and
authentification based on resources. The main resources are: /printer, /classes,
/admin and /jobs. Usually (if you take the default config file), a restriction is
defined for /admin where only root is allowed. All job operations are done on
the /jobs resources, and if you didn't set any restriction, then you can send
a request to the server, setting "requesting-user-name" to whatever you want,
the server will simply trust you. With a few line of codes, you can write an
utility to remove the print job of anyone (I tried and it works).

OTOH (and I think it's your case), if you define a basic access restriction
on the /jobs resource (== you need to be authenticated as a normal user), 
you can't do that anymore. First you need to authenticate yourself as a
normal user to access the resource, with a login/password pair. Then if the
"requesting-user-name" doesn't match the login you used, the operation is
simply forbidden. So you must authenticate yourself as the owner of the job
to remove it. Maybe "root" is a special case, I didn't try.

> If that's the case, I know which packages will meet the fate of rpm -e ASAP.

IMO, CUPS handles security gracefully and correctly. The fact is that it is
very flexible in defining access restriction on various resources, so it's
up to the admin to know what to do. You are able to remove any restriction
so that anyone can do anything, or on the opposite set "system" restriction
everywhere such that you need to be root to do anything. You can also allow
or deny access to the whole network, specific addresses, subnets, ...

Michael.

-- 
------------------------------------------------------------------
Michael Goffioul		IMEC-DESICS-MIRA
e-mail: goffioul@imec.be	(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510		Kapeldreef, 75
Fax:    +32/16/28-1515		3001 HEVERLEE, BELGIUM
------------------------------------------------------------------
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]