Bug 215133

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! :)