Bug 143321 - CancelJob ignores job ownership
CancelJob ignores job ownership
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups (Show other bugs)
3.0
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-18 18:02 EST by Robert van den Aker
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-23 10:33:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert van den Aker 2004-12-18 18:02:41 EST
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 10:00:01 EST
Confirmed.
Comment 2 Tim Waugh 2004-12-23 10:33:38 EST
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 13:12:47 EST
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 05:51:28 EST
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 06:42:06 EST
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.

Note You need to log in before you can comment on or make changes to this bug.