Description of problem: If the printing job is started as root and "lprm" is invoked as a user, it then asks for the password infinitely, not accepting any. Version-Release number of selected component (if applicable): cups-1.2.5-2.fc6.8 How reproducible: always Steps to Reproduce: 1. Print the test-page in a printconf-gui 2. Type "lprm" as user 3. Enter any password Actual results: Asks for the password infinitely Expected results: Accept the correct password and remove the print job. Or, maybe, a message that I do not have privs to cancel that print job. Or any other reasonable message will do. Additional info:
libcups only offers a callback mechanism for collecting the password, defaulting to getpass(). The callback function doesn't get to know what went wrong last time, or even if there was a last time. It's just part of the CUPS API to keep asking for a password -- compare with how the web interface works (it's much the same thing). However, defaulting to getpass() has another problem which is fixable. getpass() prevents Control-C from stopping the program. By writing our own implementation, we can make Control-C work properly. I've done this and checked it into CVS.
> It's just part of the CUPS API to keep > asking for a password -- compare with how the web interface works (it's much > the same thing). Hey hey, wait! :) Asking for the password "repeatedly" is not the same as "infinitely". The problem is not the way it asks. The problem is that it *does not accept any password*. _That_ is a bug. Asking till I enter the right one would be fine. But why asking the password if it is not intended to proceed any further but just to re-ask?
I've reported that upstream, but I doubt the behaviour will be changed.
I might be missing something here... We do agree that it asks for the password infinitely, right? We do agree that it asks in vain - any password gets just re-asked. Right? If we do agree on both the above, then I can't imagine anything on Earth that will justify such a behaveour. Why "CUPS just works that way"? Why "the behaviour will unlikely to be changed"? I simply don't understand. If that behaveour is correct, or if there is some "rationale" behind it, then my question is simply: why such a behaviour is needed? Why asking for the password and ignore it? If there is even a slight reason behind it then I'll stop bothering you immediately. :) OTOH, if there is no reason at all, and it asks the password for just to annoy the user, then I don't understand why you think this is OK and won't be changed...
Well, follow up on the upstream bug report: http://cups.org/str.php?L2101
Hmm, it looks typical for this bugzilla to stay down for a few months... Maybe a dumb question, but... why not to use some other HTTP error replies too? If "Unauthorized" means that the auth have failed and the one should retry, then why not to use, for instance, "Forbidden" reply when the user have properly authenticated himself but does not have the privs to perform the task? It looks (from the link you pointed) like currently there is no distinction between the failed auth (login/pass mismatch etc) and the insufficiency of privs, and that makes the problem. Is it really difficult to separate these cases, or am I missing the point?
I've echoed that in the upstream bug report. However, I wonder about the security implications of that approach. We'll see what the upstream opinion is.
Hmm, this bug appeared to have been closed, probably unintentionally - reopening. Or what was that? At least I do not see it fixed at all. :)
No upstream response yet.
"Considering for 1.4..." is the only upstream response so far.
Thank you, lets promote it to F8 then. Right? :)
Hi. I've just tested that, and no, nothing is fixed. The only change is that now if I press Enter without typing any password, lprm exits and says: "lprm: Unauthorized". Still, the valid or the invalid password just causes the password being re-asked. Nothing have been changed, AFAICS.
On Fedora 10, entering a valid password for a user that is not authorised for a particular action gives 'Forbidden'. For example: $ lpadmin -p foo -v /dev/null lpadmin: Forbidden Here, it knows who I am because of communicating over a UNIX domain socket. Let's communicate only over an IP socket so it isn't sure who I am unless I provide a password. I'll enter an incorrect password first, then the correct password: $ CUPS_SERVER=127.0.0.1 lpadmin -p foo -v /dev/null Password for tim on 127.0.0.1? Password for tim on 127.0.0.1? lpadmin: Forbidden cups-1.3.9-8.fc10
Hi Tim. lpadmin behaves the way you described, but this bug is about lprm. Please check and see that the lprm behaves the way I described. So should I re-open this again? :)
Not to get you annoyed, but since the lprm is still broken for me, I think it would be better to have that bug opened for now. :)
In the default configuration lprm doesn't require a password. Please attach cupsd.conf from the server which is requiring one.
Created attachment 343428 [details] /etc/cups/cupsd.conf Please note that the password is asked only if the job was started by the other user than the one executing lprm. I actually only tried root starting the job and the user executing lprm. The behaveour is still the same, with the only difference that if the empty password is typed, lprm exits. This is an improvement from some point of view, but I have the passwordless user accounts, which must be handled somehow as well.
Yes, I see. The HTTP_FORBIDDEN behaviour was only being applied to denials based on request location, not those based on policy. I've filed STR #3191 upstream to track that.
Rejected upstream.
So the upstream is completely unhelpfull - would it be possible for the local fix in fedora?
One last go upstream. No, we don't want to carry around patches that are not upstream. Better to get fixes upstream so everybody benefits.
> One last go upstream. No, we don't want to carry around patches that are not > upstream. Better to get fixes upstream so everybody benefits. Except for the cases when the upstream doesn't want them. :) Thanks for filling it upstream, lets keep that bug tracked for now. :)
This will be fixed in Fedora 11 when cups-1.4rc1 (or later) is made a stable update.
Confirming the fix. It now doesn't even ask for the password at all, just saying "Forbidden" right away. That's a good thing. Thanks for your work on that! :)