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.
Confirmed.
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.
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.
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.