Bug 215133 - lprm asks for the password infinitely
lprm asks for the password infinitely
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
http://cups.org/str.php?L3191
: Reopened
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2006-11-11 03:56 EST by Stas Sergeev
Modified: 2009-07-28 14:25 EDT (History)
0 users

See Also:
Fixed In Version: 1.3.8-4.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 05:04:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/etc/cups/cupsd.conf (2.43 KB, text/plain)
2009-05-11 07:32 EDT, Stas Sergeev
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 2101 None None None Never
CUPS Bugs and Features 3193 None None None Never

  None (edit)
Description Stas Sergeev 2006-11-11 03:56:52 EST
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:
Comment 1 Tim Waugh 2006-11-13 11:26:54 EST
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.
Comment 2 Stas Sergeev 2006-11-13 14:54:30 EST
> 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?
Comment 3 Tim Waugh 2006-11-14 09:47:29 EST
I've reported that upstream, but I doubt the behaviour will be changed.
Comment 4 Stas Sergeev 2006-11-14 13:47:13 EST
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...
Comment 5 Tim Waugh 2006-11-15 04:53:08 EST
Well, follow up on the upstream bug report:

  http://cups.org/str.php?L2101
Comment 6 Stas Sergeev 2007-01-03 16:16:23 EST
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?
Comment 7 Tim Waugh 2007-01-05 11:26:48 EST
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.
Comment 8 Stas Sergeev 2007-01-05 14:49:19 EST
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. :)
Comment 9 Tim Waugh 2007-02-09 07:01:50 EST
No upstream response yet.
Comment 10 Tim Waugh 2008-02-26 10:25:00 EST
"Considering for 1.4..." is the only upstream response so far.
Comment 11 Stas Sergeev 2008-02-26 13:31:47 EST
Thank you, lets promote it to F8 then.
Right? :)
Comment 12 Stas Sergeev 2009-02-06 16:41:34 EST
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.
Comment 13 Tim Waugh 2009-02-09 07:48:22 EST
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
Comment 14 Stas Sergeev 2009-02-09 08:01:09 EST
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? :)
Comment 15 Stas Sergeev 2009-02-09 09:52:30 EST
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. :)
Comment 16 Tim Waugh 2009-05-11 06:24:54 EDT
In the default configuration lprm doesn't require a password.

Please attach cupsd.conf from the server which is requiring one.
Comment 17 Stas Sergeev 2009-05-11 07:32:12 EDT
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.
Comment 18 Tim Waugh 2009-05-11 09:26:57 EDT
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.
Comment 19 Tim Waugh 2009-05-12 13:34:56 EDT
Rejected upstream.
Comment 20 Stas Sergeev 2009-05-12 14:39:53 EDT
So the upstream is completely unhelpfull -
would it be possible for the local fix in
fedora?
Comment 21 Tim Waugh 2009-05-13 05:22:30 EDT
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.
Comment 22 Stas Sergeev 2009-05-13 06:15:17 EDT
> 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. :)
Comment 23 Tim Waugh 2009-07-03 05:04:25 EDT
This will be fixed in Fedora 11 when cups-1.4rc1 (or later) is made a stable update.
Comment 24 Stas Sergeev 2009-07-28 14:25:51 EDT
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! :)

Note You need to log in before you can comment on or make changes to this bug.