Description of problem: Cups is allowing users to delete other user's job without asking for a password. Version-Release number of selected component (if applicable): [root@zaphod cups]# rpm -qa | grep cups cups-libs-1.2.4-11.5.el5 cups-libs-1.2.4-11.5.el5 cups-1.2.4-11.5.el5 [root@zaphod cups]# How reproducible: always Steps to Reproduce: 1. log in as any user (may be root) 2. pause printing with cupsdisable 3. enqueue a job with lpr -P <printer-instance> <file> 4. list jobs with lpq and pick the latest job-id 5. log in as a different user 6. remove job with 'lprm -U <owner> <job-id>' Actual results: User can remove other user's jobs Expected results: User can only remove it's own job Additional info: Seems that the problem is with the '-U <owner>' param, that didn't exist in RHEL4 - somehow it's overriding the user check with the provided user This is required for LSPP evaluation, but it can be overridden by a change (see workaround below) in the cups configuration in the lspp config script (cc'ing Klaus Weidner about this). The workaround is to require 'AuthType Basic' in the 'Cancel-Job' policy in the cupsd.conf file, but that's not the distro default. This will require the user to authenticate himself every time he cancels a job, even if it's his own job.
I was able to reproduce the same behavior on a straight rhel5/targeted system with the default cupsd.conf, which has this: # Only the owner or an administrator can cancel or authenticate a job... <Limit Cancel-Job CUPS-Authenticate-Job> Require user @OWNER @SYSTEM Order deny,allow </Limit> According to the comment, it seems that the behavior we're seeing isn't right. Is the cupsd.conf file wrong or is the code not doing the right thing?
This is how CUPS is intended to work, yes. The 'Require user' with no AuthType is basically a protection against accidentally cancelling someone else's job. The cancel request is sent over IPP, with a 'requesting-user' attribute. How that attribute is validated depends on the AuthType.
So is the comment in the cupsd.conf file wrong then? It says that only the owner or an administrator can cancel a job but that is not the case. It seems like this feature will surprise people. In RHEL4 you cannot cancel someone else job but in RHEL5 you can by default? Seems like the default settings should be the same and if someone wants to relax their system then they can choose to do that.
Well, the comment might be strictly correct depending on what the AuthType is. The server behaviour isn't any different from RHEL-4: if someone made their own 'cancel' binary by making a CUPS API application, or took the RHEL-5 one, and ran it against a RHEL-4 scheduler the same would apply. I've filed a bug upstream about the default configuration, to gather feedback about changing it.
Upstream response to "Perhaps there should be an 'AuthType Basic' for job cancellation in the default configuration?": "No, because then you can't do "cancel 123" from the command-line without providing a password, which will be a) annoying and b) break existing installs." I tend to agree -- if it is really a requirement that users authenticate themselves before they are allowed to cancel a job, that change is best made at the site level. That said, perhaps a better authentication scheme, not requiring passwords when authenticating as the current user, could be created.
or at least fix the comment in the cupds.conf file so it describes the behavior correctly. I still think its bogus that in RHEL4 a user can't cancel another user's job with the default setting and with RHEL5, a user can. I think the inconsistent behavior will bother people, once they realize its there. Is there really no authentication scheme that works like it used to? If we're going to leave the behavior as it is, then I think we need to at least fix the comment.
I'd like to re-iterate what I said in comment #4: the server behaviour in RHEL-5 is no different in this respect than it was in RHEL-4. There is no user authentication for cancelling jobs in the default configuration. The difference is that the 'cancel' command now provides a '-U' option for asserting a different username than the current one. Changing the comment is a good idea. Unfortunately it is more than just changing the default cupsd.conf file we ship since occasionally that file will be generated by cupsd itself. I have submitted STR #2274 with some suggested wording, to try to keep in step with the upstream source.
I saw what you said in comment #4 and don't want to beat a dead horse but from a user's perspective, the behavior is very different. In RHEL-4 I'm not able to cancel someone else's job. I get an error telling me its not my job. I don't know where the enforcement happens but that's the behavior I see. With RHEL5 and the introduction of the -U flag on lprm, I'm able to cancel another user's job. If I'm going to assert a different user, shouldn't I at least have to athenticate?
You still get that same error on RHEL-5 except if you use the -U flag. > In RHEL-4 I'm not able to cancel someone else's job. Well, unless you use a 'cancel' binary that provides a -U option, or write yourself a little program to submit an IPP request with a different requesting-user-name attribute. Or (for that matter) unless you run 'cancel' under gdb.. > If I'm going to assert a different user, shouldn't I at > least have to athenticate? The point is that the *server* needs to authenticate if it is to be an authenticated action. All '-U' does at the client end is put a different user name in the IPP request. The server just compares the requesting-user-name attribute with the owner of the job (i.e. the requesting-user-name attribute that was given in the create-job IPP request). If 'AuthType Basic' is set, *all* users have to authenticate, regardless of whether -U was used for the client program submitting the request. So it isn't a case of 'assert different user -> have to authenticate' -- user authentication is either on or off (for each particular action; here we're talking about cancel-job). It sounds like you're asking for a return to the RHEL-4 state of affairs, which is equivalent to patching out the '-U' option in the cancel/lprm program and leaving the default configuration alone. Is that right?
> If 'AuthType Basic' is set, *all* users have to authenticate, regardless > of whether -U was used for the client program submitting the request. > So it isn't a case of 'assert different user -> have to authenticate' -- > user authentication is either on or off (for each particular action; > here we're talking about cancel-job). What I see on my RHEL5 installation is that a normal user I can cancel my own job without authenticating. If I try to cancel someone else's job I'm asked to authenticate but it my passwd isn't accepted. If I try to cancel someone else's job and use the -U, it works. [ljk@kipper ~]$ lpq hoare is not ready Rank Owner Job File(s) Total Size 1st root 7 passwd 2048 bytes 2nd ljk 8 group 1024 bytes [ljk@kipper ~]$ lprm 8 [ljk@kipper ~]$ lprm 7 Password for ljk on localhost? Password for ljk on localhost? Password for ljk on localhost? Password for ljk on localhost? lprm: Unauthorized [ljk@kipper ~]$ lprm -U root 7 The behavior I'm seeing doesn't seem to match your description of how it should work. What passwd was it looking for when it prompted me? (My passwd and the root passwd are the same on this system.) If you're saying that in RHEL4, cupsd always supported this behavior but RHEL4 shipped no commands to take advantage of it then I buy that. However, now you're shipping commands that take advantage if it, it seems like you're introduced a security problem. I also don't understand why lpadmin behaves differently from cancel. In the lpadmin case, I can use -U but it wants root's paswd: [ljk@kipper ~]$ /usr/sbin/lpadmin -U root -p ljkprinter -D "created as ljk" Password for root on localhost? [ljk@kipper ~]$ That's how I'd expect lprm to work with -U. I get that behavior once I added AuthType Basic here: # Only the owner or an administrator can cancel or authenticate a job... <Limit Cancel-Job CUPS-Authenticate-Job> AuthType Basic Require user @OWNER @SYSTEM Order deny,allow </Limit> I guess the bottom line is that if the -U option is going to be there, then by default it ought torequire authentication. If that means also authenticating users managing their own jobs, its annoying but preferable to the way it is now. I think the problem with the "-U" flag is greater than just canceling jobs. I'm able to queue a job as another user too. [ljk@kipper ~]$ lpr -U root /etc/passwd [ljk@kipper ~]$ lpq hoare is not ready Rank Owner Job File(s) Total Size 1st root 12 passwd 2048 bytes [ljk@kipper ~]$ That seems way too permissive for a default configuration.
I would agree with Linda. I think that users should not be able to cancel each other's jobs without explicitly allowing it in the config. The admin should be able to cancel anything. I think this is reasonable behavior. Regarding queueing jobs as another user, that is something that has to be fixed.
What you are asking is that every time anyone (a) prints, or (b) cancels a job, they are asked for their password. Right-clicking on a printing job in the job manager and selecting Cancel: password prompt (note: this isn't even implemented as far as I am aware). File->Print from any application: password prompt. (Is this implemented by any applications?) I really don't see this being acceptable to the majority of users.
See STR #2277 for a first attempt at a patch to implement UNIX domain socket authentication.
Klaus, can you provide feedback on this bug?
CAPP/LSPP don't have specific requirements for the handling of the printer queue. There is the general requirement that if audit records are generated for user actions the loginuid must match the actual submitting user and not an impersonated user. If authentication is involved, the usual rules apply, including audit of all authentication, use of pam_tally2 or equivalent to lock out users after too many invalid password guesses, and respecting password expiry and other standard PAM auth features. I agree with Linda and Steve that allowing users to delete and submit jobs as a different user (with no authentication) is very unexpected, and I agree also with Tim that it's unacceptable to prompt for the password even in the default case of submitting or cancelling jobs as yourself. I only briefly looked at the proposed approach on the mailing list, but using the credentials provided by the kernel sounds like a good approach.
I tested this patch in combination with the latest cups-lspp.patch and everthing works correctly. When attempting to remove another user's job via the -U option I am prompted for that user's password. When removing my own jobs with or without the -U option I am not prompted.
This looks good. tested with 1.2.4-11.6.el5 and seems fixed. But isn't upstream yet, is it? You may close the bug
1.2.4-11.6.el5 does not contain the fix. No, the patch is not upstream yet, and I have not yet had feedback about it.
(In reply to comment #19) > 1.2.4-11.6.el5 does not contain the fix. > > No, the patch is not upstream yet, and I have not yet had feedback about it. I was trying to remove a root-owned job using a regular user (like I did in the first testcase in #0) and was asked about the root's password every time, so I thought it was fixed. But the behavior indeed changed. Seems like because of the patch to #229673, now MAC checks are being applied to this operation, so when in enforcing mode, even when specifying '-U root' and the correct root password, I am unable to remove the job. And when in permissive mode, I am still able to remove everyone's job without being asked for a password. This looks strange to me since I'd expect something like 'lprm: Job #00 does not exist!' when trying to delete a job from a user who's domain is inaccessible. I don't think lspp has a requirement about this, though - so just FYI.
With regards to "now MAC checks are being applied to this operation, so when in enforcing mode, even when specifying '-U root' and the correct root password, I am unable to remove the job." I think its better to say RBAC checks are being applied. In enforcing mode, even with the correct password, users are unable to delete other's jobs from the queue unless they are in a role which has permissions to manage the queue. When I gave the correct password from staff_r I was not able to delete a job, but once changed to sysadm_r I was able to remove the job. As for permissive mode, I am still prompted for a password. Although permissive mode is not supported I'd still expect to see consistent behavior, perhaps you could elaborate on how you setup your test in permissive mode.
(In reply to comment #22) > As for permissive mode, I am still prompted for a password. Although permissive > mode is not supported I'd still expect to see consistent behavior, perhaps you > could elaborate on how you setup your test in permissive mode. Have you removed the 'AuthType Basic' from the Cancel job policy?
No I still have that there. I was confused on this as well so I email'ed Tim and this is what he said: No. Just set "AuthType Basic" or any other authentication scheme you like, and the client will ask the server to use getsockopt(SO_PEERCRED) if (a) it failed to authenticate using a certificate, (b) it is over an AF_LOCAL socket, and (c) it is authenticating as the current user. It is basically an extension of the certificates mechanism. ---- So with the patch Tim created we still need to have 'AuthType Basic' just that the patch makes it so the server doesn't prompt for a password when you're not masquerading as a different user.
Is the fix to bug #229673 not working as expected? If that is the case, please add a note to that bug report. For *this* bug (bug #230613), 'AuthType Basic' is needed for any operations that are to be authenticated (such as Cancel-Job), and the SO_PEERCRED patch effectively by-passes the 'Basic' authentication similarly to the way a root certificate (i.e. providing the contents of /var/run/cups/certs/0) does. However, I have not yet built a CUPS package for Red Hat Enterprise Linux 5 containing this patch. This will come soon.
No, bug #229673 fixed and working as expected from my testing. Have you got feedback from mainstream Cups about this one? This is one of two or three packages that we are awaiting for the final (LSPP) version.
tested, 1:1.2.4-11.8 seems to fix this problem
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-1020.html