Red Hat Bugzilla – Bug 143321
CancelJob ignores job ownership
Last modified: 2007-11-30 17:07:05 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):
Steps to Reproduce:
1.jack$ lp -d printer /etc/motd
2.jill$ cancel -u jack printer-123
Actual Results: jack's job gets cancelled
Expected Results: cancel: cancel-job failed: client-error-forbidden
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.
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
Thanks for your report.
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
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"!
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.