Bug 143321

Summary: CancelJob ignores job ownership
Product: Red Hat Enterprise Linux 3 Reporter: Robert van den Aker <robert2>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-23 15:33:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert van den Aker 2004-12-18 23:02:41 UTC
Description of problem:
After I submit a print job as user A, I can cancel it as user B. Jobs
were submitted with lp and lpr and cancelled with cancel, lprm and
from the web interface. Clients were the local CUPS 1.1.17 client
programs and remote CUPS 1.1.20 and 1.1.22 clients. Newer CUPS servers
(at least from 1.1.20) do not have this bug.

Version-Release number of selected component (if applicable):
cups-1.1.17-13.3.16

How reproducible:
Always

Steps to Reproduce:
1.jack$ lp -d printer /etc/motd
2.jill$ cancel -u jack printer-123
3.
    

Actual Results:  jack's job gets cancelled

Expected Results:  cancel: cancel-job failed: client-error-forbidden

Additional info:

Also, when the "/" and/or "/jobs" Locations are password-protected,
the different CUPS client versions ask for different passwords with
the cancel command. In the example above a CUPS 1.1.17 client asks for
jack's password (correctly IMHO) while 1.1.20 and 1.1.22 clients ask
for jill's password.

Comment 1 Tim Waugh 2004-12-23 15:00:01 UTC
Confirmed.

Comment 2 Tim Waugh 2004-12-23 15:33:38 UTC
This behaviour is expected unless you have taken steps to password-protect the
/jobs location -- see the cancel man page.

The issue concerning which user's password needs to be entered has been filed
upstream: http://www.cups.org/str.php?L1028

Thanks for your report.

Comment 3 Robert van den Aker 2004-12-23 18:12:47 UTC
Password-protecting the /jobs location is not an adequate solution. A user 
only needs to know his/her own password to cancel anybody else's jobs 
(assuming you want all users to be able to access /jobs).
I read the cancel man page and know this is documented behavior, but 
it's undesirable behavior and has been fixed in more recent versions of 
CUPS. I believe a backport of the fix (whatever it was) should be 
considered.

Comment 4 Tim Waugh 2004-12-24 10:51:28 UTC
This does not seem to be the case in my testing.

With a 1.1.17-13.3.x server:

* same-version clients ask for the owning user's password
* newer clients ask for the invoking user's password -- and fail:

$ cancel -h server -u owner deskjet-990c-1-10
Password for tim on server?
cancel: cancel-job failed: client-error-forbidden

and on the server's error_log:

E [24/Dec/2004:10:24:14 +0000] cancel_job: "tim" not authorized to delete job id
10 owned by "owner"!


Comment 5 Robert van den Aker 2004-12-24 11:42:06 UTC
Oops!!! My bad. Next time I'll try to think before I submit a bug report. I
forgot that I had changed the SystemGroup in cupsd.conf and that I had made user
"robert" a member of this group. All my tests were with user "robert" cancelling
other users' jobs. I just submitted a job as "robert" and tried to cancel it as
a user who's not a member of the SystemGroup and it failed as it should. Please
accept my apologies for wasting your time on this.