| Summary: | Catch and report failure to open qpidd.sasldb when PLAIN authentication is enabled | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Trevor McKay <tmckay> | ||||||
| Component: | qpid-cpp | Assignee: | Ernie <eallen> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | mick <mgoulish> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | Development | CC: | bbreard, bkozdemb, jross, lzhaldyb, matt, mgoulish, sgraf, tross | ||||||
| Target Milestone: | 3.0 | Keywords: | EasyFix, Improvement, Patch | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | qpid-cpp-0.22-4.el6, qpid-cpp-0.22-4.el5 | Doc Type: | Enhancement | ||||||
| Doc Text: |
This enhancement adds a qpid log message, which indicates the SASL database could be missing or have the wrong permission. There was no qpid log message that indicated there could be a problem with the SASL database file permission. The only log message was in the system log. The qpid log now contains an indication of what the problem may be when authentication is denied for a user.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-09-24 15:03:17 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Trevor McKay
2011-08-26 18:07:08 UTC
We had another Red Hatter bitten by this. I am becoming concerned. That's 2 in about a week. I am guessing that what is happening is that users are installing sasldb to provide authentication during install of a new system, but they are doing it as the root user. Apparently, there are no notes indicating that the qpidd user needs to be the owner of /var/lib/qpidd/qpidd.sasldb. I definitely think we need some docs on this, and some kind of run time error as well if possible. <lightbulb!> Had an idea. What if we just modify the init.d script for the qpidd service to check for /var/lib/qpidd/qpidd.sasldb and force the ownership to qpidd:qpidd if it's not already? Make the problem go away instead of relying on docs or user response to an error message. see also 735358 As far as the runtime error goes, it was noted that permission errors will show up in /var/log/messages. This has been added to the MCIG. Perhaps this is sufficient? (In reply to comment #4) > As far as the runtime error goes, it was noted that permission errors will > show up in /var/log/messages. This has been added to the MCIG. Perhaps > this is sufficient? As long as the file access error is reported in qpid logging, I think it's resolved. Assigning to Chuck to check. Created attachment 714727 [details]
Trace for connection request
The file access error is not reported in the qpid logging. The only error reported is that the user is not found ... 2013-03-22 15:06:00 [Security] info qpid/broker/SaslAuthenticator.cpp:415:qpid::broker::CyrusAuthenticator::start: SASL: Starting authentication with mechanism: PLAIN 2013-03-22 15:06:00 [Security] info qpid/broker/SaslAuthenticator.cpp:473:qpid::broker::CyrusAuthenticator::processAuthenticationStep: SASL: Authentication failed for guest@QPID:SASL(-13): user not found: Password verification failed 2013-03-22 15:06:00 [System] debug qpid/Exception.cpp:43:qpid::Exception::Exception: Exception constructed: Authentication failed ... The full trace for the request is in the attachment. However, the /var/log/messages file does show the error: Mar 22 15:06:00 redhat qpidd: unable to open Berkeley db /home/ernie/workspace/qpid-trunk/cpp/src/tests/sasl_config/qpidd.sasldb: Permission denied Note: the qpid logs show the same messages if qpidd.sasldb is missing. That is it only reports user not found: Password verification failed. In SaslAuthenticator::init we are checking for the existence of the sasl_config directory and if the directory is writable. But we are not checking if the db is present and writable. Being more specific: The Berkeley library is not returning a permission denied or file not found error on the qpid.sasldb file. It only returns that the user was not found. Created attachment 717063 [details]
Change qpid log message
When the sasldb is not accessible (file permissions or not found) the error code returned from the library call is SASL_NOUSER. However, that is the same code returned when the user name supplied was not in the sasldb.
This patch changes the qpid log message to indicate that one of those two cases happened.
Notes:
- When the supplied password doesn't match what is in the sasldb, SASL_BADAUTH is returned. The log message for that case is unchanged.
- It would be possible to retrieve the sasldb name from the config file and check it for permissions/existence, but that would be a more involved change with basically the same result.
Here is the log message when the sasdb is not accessible:
2013-03-27 09:11:51 [Security] info qpid/broker/SaslAuthenticator.cpp:478:qpid::broker::CyrusAuthenticator::processAuthenticationStep: SASL: Authentication failed. User not found or sasldb not accessible.(-20) for guest@QPID
bug verified on : RHEL 6.4 , x86_64
fix verified on : { RHEL 5.9 , RHEL 6.4 } x { 32-bit, 64-bit}
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1296.html |