Hide Forgot
Description of problem: A case came up in which the sasl database /var/lib/qpidd/qpidd.sasldb had ownership of root:root instead of qpidd:qpidd. This prevented the qpidd user from reading the authentication database, and consequently authenticated connections to the broker didn't work. Not sure how this happened, but it may be common enough now that the sasldb is not shipped with the default install. If qpidd does not already catch and report a failure to open qpidd.sasldb, maybe it should. This took a bit of time to track down on the system in question. Additionally, a note mentioning ownership in the docs that covers installation of the sasldb might be in order. Version-Release number of selected component (if applicable): qpid-cpp-server-0.10-6.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Set up a qpidd install with PLAIN authentication configured 2. Set the ownership of /var/lib/qpidd.sasldb to root:root, and chmod 600 3. Start or restart the qpidd service 3. Try to connect to the broker with user/password info, for example with qpid-stat -c. Connection will fail. 4. Set the ownership of the file to qpidd:qpidd. 5. Restart the qpidd service 6. Try to connect to the broker again, connection should succeed Actual results: Not sure, maybe there is already a log or error reported somewhere that indicates the problem. Expected results: There should be an error that lets the user know the sasl db could not be opened. Additional info:
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
-> POST http://svn.apache.org/viewvc?view=revision&revision=1470065
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