Bug 143321
Summary: | CancelJob ignores job ownership | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Robert van den Aker <robert2> |
Component: | cups | Assignee: | 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
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. |