OpenBSD, web interface: authentication works, but not authorization #5166
Comments
|
I forgot to mention that it works fine as the root user. |
|
Hmm, it should be getting the local authentication certificate from the certs directory - can you attach your /etc/cups/cups-files.conf file? I'm wondering if something is messed up with the directory used for passing credentials to the CGI programs? |
|
Sure, here you go. |
|
OK, that looks pretty standard, so can you send me the output of: The certs directory is the one the CGI programs will need to be able to access... |
|
Here you go: |
|
OK, that should be enough for the CGIs to get the local certs... Alright, try enabling debug2 logging ("cupsctl LogLevel=debug2") and see what is coming from the CGI Get-Devices request... |
|
Here's the error log. I really don't understand what is going on :-/ ... |
|
So the new log shows admin.cgi getting run and then the CUPS-Get-Devices operation being done over a domain socket which (correctly) gets the logged-in credentials from the cert cache, but then it thinks that ajacoutot is not a member of group wheel... Can you verify that your user account is, in fact, listed in /etc/groups for the wheel account? |
|
It is :-) At least I have a better hint of where to look at in the code.. |
|
Well, the CUPS group lookup code is not seeing it - are you using LDAP or other network account stuff on this system? Something that might prevent /etc/group from being the first to get looked up? |
|
Nope, only using flat files. No external authentication. |
|
group->gr_gid looks corrupted somehow. If I print "group->gr_gid groups[i]", I have the following in the logs: |
|
Ok I found the cullprit. Our getgrouplist(3) implementation has a documented bug: So the solution would be to either:
I'd rather not open a pull request until you advise me what you prefered solution would be. |
|
Works like a charm \o/ |
- Fixed a compile issue when PAM is not available (Issue #5253) - Documentation fixes (Issue #5252) - Star Micronics printers need the "unidir" USB quirk rule (Issue #5251) - The scheduler now supports using temporary print queues for older IPP/1.1 print queues like those shared by CUPS 1.3 and earlier (Issue #5241) - The `cupsRasterWritePixels` function did not correctly swap bytes for some formats (Issue #5225) - Added a USB quirk rule for Canon MP280 series printers (Issue #5221) - The `ppdInstallableConflict` tested too many constraints (Issue #5213) - More fixes for printing to old CUPS servers (Issue #5211) - The `cupsCopyDest` function now correctly copies the `is_default` value (Issue #5208) - The scheduler did not work with older versions of uClibc (Issue #5188) - The scheduler now substitutes default values for invalid job attributes when running in "relaxed conformance" mode (Issue #5186) - Fixed PAM module detection and added support for the common PAM definitions (Issue #5185) - Fixed a journald support bug in the scheduler (Issue #5181) - The cups-driverd program incorrectly stopped scanning PPDs as soon as a loop was seen (Issue #5170) - Fixed group validation on OpenBSD (Issue #5166) - Fixed the `ippserver` sample code when threading is disabled or unavailable (Issue #5154) - The `cupsEnumDests` function did not include options from the lpoptions files (Issue #5144) - The `SSLOptions` directive now supports `MinTLS` and `MaxTLS` options to control the minimum and maximum TLS versions that will be allowed, respectively (Issue #5119) - The scheduler did not write out dirty configuration and state files if there were open client connections (Issue #5118) - The `lpadmin` command now provides a better error message when an unsupported System V interface script is used (Issue #5111) - The `lp` and `lpr` commands now provide better error messages when the default printer cannot be found (Issue #5096) - No longer support backslash, question mark, or quotes in printer names (Issue #4966) - The CUPS library now supports the latest HTTP Digest authentication specification including support for SHA-256 (Issue #4862) - The `lpstat` command now reports when new jobs are being held (Issue #4761) - The `lpoptions` command incorrectly saved default options (Issue #4717) - The `ppdLocalizeIPPReason` function incorrectly returned a localized version of "none" (rdar:https://36566269) - TLS connections now properly timeout (rdar:https://34938533) - The IPP backend did not properly detect failed PDF prints (rdar:https://34055474)
Hi.
I am running CUPS 2.2.6 on OpenBSD/amd64.
As a member or the wheel group (which is included in SystemGroup), I cannot manage printers over the web interface. External clients (like using the GNOME print dialog) works fine.
Here's an hopefully relevant extract from the cups error_log in debug mode.
Authentication works fine but I am puzzled by this entry:
cupsdIsAuthorized: username=""which may be the reason forReturning HTTP Unauthorized for CUPS-Get-Devices (no URI) from localhost.The text was updated successfully, but these errors were encountered: