Bug 733758 - Catch and report failure to open qpidd.sasldb when PLAIN authentication is enabled
Catch and report failure to open qpidd.sasldb when PLAIN authentication is en...
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Development
Unspecified Unspecified
medium Severity medium
: 3.0
: ---
Assigned To: Ernie
mick
: EasyFix, Improvement, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-26 14:07 EDT by Trevor McKay
Modified: 2014-09-24 11:03 EDT (History)
8 users (show)

See Also:
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 11:03:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Trace for connection request (5.03 KB, text/plain)
2013-03-22 15:11 EDT, Ernie
no flags Details
Change qpid log message (1.01 KB, patch)
2013-03-27 09:15 EDT, Ernie
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-4757 None None None Never

  None (edit)
Description Trevor McKay 2011-08-26 14:07:08 EDT
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:
Comment 1 Trevor McKay 2011-09-01 15:53:53 EDT
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.
Comment 2 Trevor McKay 2011-09-01 17:28:25 EDT
<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.
Comment 3 Trevor McKay 2011-09-02 13:43:55 EDT
see also 735358
Comment 4 Trevor McKay 2011-10-27 13:13:36 EDT
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?
Comment 5 Justin Ross 2012-12-10 16:40:15 EST
(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.
Comment 8 Ernie 2013-03-22 15:11:15 EDT
Created attachment 714727 [details]
Trace for connection request
Comment 9 Ernie 2013-03-25 11:34:58 EDT
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.
Comment 10 Ernie 2013-03-25 14:07:43 EDT
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.
Comment 11 Ernie 2013-03-27 09:15:40 EDT
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
Comment 12 Justin Ross 2013-04-20 06:33:26 EDT
-> POST

http://svn.apache.org/viewvc?view=revision&revision=1470065
Comment 13 mick 2013-07-15 21:32:04 EDT
bug verified on :   RHEL 6.4 , x86_64


fix verified on :   { RHEL 5.9 , RHEL 6.4 } x { 32-bit, 64-bit}
Comment 16 errata-xmlrpc 2014-09-24 11:03:17 EDT
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

Note You need to log in before you can comment on or make changes to this bug.