| Summary: | Endless loop when configuring a printer from central CUPS server and permission denied (403) | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] print-manager | Reporter: | Oliver Freyermuth <o.freyermuth> |
| Component: | general | Assignee: | Daniel Nicoletti <dantti12> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | simonandric5 |
| Priority: | NOR | ||
| Version: | 0.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 17.08.2 | |
| Sentry Crash Report: | |||
|
Description
Oliver Freyermuth
2017-08-09 08:47:21 UTC
I believe the endless loop starts here: https://github.com/KDE/print-manager/blob/afd4609014e9aa938cb02be858f880deb56ade8e/libkcups/KCupsRequest.cpp#L564 That line is only a problem if there is a programming error with Qt parenting, which is unlikely. What can help here is the server configuration tho I sadly don't have much more time to investigate issues on this. Well, if the server responds with 403 but the client retries (endlessly), I'd say it's clearly a client-side bug. So something must go wrong with the error handling in the forked connection thread. The related CUPS server config part is: <Location /admin> Order allow,deny Allow from INSERTADMINHOSTIPHERE </Location> Of course I am trying from a normal client, not the admin machine. You made me have a deeper look at the code, the bug is obvious in: https://github.com/KDE/print-manager/blob/master/libkcups/KCupsConnection.cpp 1) KCupsConnection::request() calls retry(). 2) KCupsConnection::retry() handles (status == IPP_FORBIDDEN), and if password_retries == 0, will set force_auth to true. 3) If force_auth is true, cupsDoAuthentication will be called. 4) cupsDoAuthentication will NOT call the password_cb callback, since it will (again) get a 403. for this reason, password_retries will NOT be bumped. 5) Since cupsDoAuthentication returned -1, KCupsConnection::retry() will return true. 6) We go back to Step 1. That will happen endlessly. On a side-note, debug output is broken: qCDebug(LIBKCUPS) << "Called cupsDoAuthentication(), success:" << (ret == -1 ? true : false); Here "-1" indicates failure, not success. Does this help to resolve the issue? If you allow for a comment: I'd say relying on the callback function to work (and thus relying on cups API callback behaviour to break the loop) is not a good idea in general. Maybe, at least as additional safety, it is better to have an additional exit condition. Can you confirm my understanding of the code is correct? If yes, and you tell me which way you prefer it to be solved: a) adding an additional error counting mechanism independent from the callback b) immedate erroring if 403 is received when attempted as root user c) both I could also prepare a PR. To be honest I'm not sure what is best. I think b is received if the password is wrong, but I'm not sure (old code :P) if you can try both solutions would be great, I'll have more time to look into this in around 2 weeks, so please ping me. Thanks. Hi, it seems you are correct, the CUPS server may also return 403 if the user uses a wrong password (I was pretty sure it would return NOT_AUTHENTICATED or NOT_AUTHORIZED in that case...). Based on that, I have created a very generic fix: https://github.com/KDE/print-manager/pull/2 It works for me against a CUPS-Server with IP whitelist / blacklist (i.e. no endless loop anymore!), and I can still authenticate to a local CUPS as root. Hi, just to document: I have now uploaded the PR, as seems to be the correct way for KDE contributions, to: https://phabricator.kde.org/D7325 Hi, here the friendly "ping", as requested. Cheers, Oliver |