Bug 214238 - SASL plug-in path is hardcoded
SASL plug-in path is hardcoded
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - SASL (Show other bugs)
1.0.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
:
Depends On:
Blocks: 152373 240316
  Show dependency treegraph
 
Reported: 2006-11-06 13:58 EST by Nathan Kinder
Modified: 2015-12-07 11:46 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:46:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CVS Diffs (13.90 KB, patch)
2006-11-06 13:58 EST, Nathan Kinder
no flags Details | Diff
CVS Commit Message (1.28 KB, text/plain)
2006-11-06 14:35 EST, Nathan Kinder
no flags Details
Additional CVS Diff (3.88 KB, patch)
2006-11-06 18:21 EST, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Nathan Kinder 2006-11-06 13:58:46 EST
The SASL plug-in path is hardcoded in the SASL_CB_GETPATH callback function. 
This is causing SASL to not find any of it's plug-ins on Solaris and HP-UX since
we've switched the package structure around.  SASL works fine on Linux since we
don't register the callback function and instead use the default system location
for SASL (/usr/lib/sasl2).

We should make the SASL plug-in location configurable and make the configuration
parameters work the same regardless of the platform.  The attached changes add a
new configuration parameter for setting the SASL path (nsslapd-saslpath).  We
will register the SASL_CB_GETPATH callback on all platforms.  This callback will
use the nsslapd-saslpath setting if it is set, otherwise it will try to use the
SASL_PATH environment variable.  If neither of these are set, we will use the
default path of "/usr/lib/sasl2".  For a default instance, we will not set
nsslapd-saslpath on Linux since we use the system SASL.  On HP-UX and Solaris,
we will set nsslapd-saslpath to point to the SASL plug-ins that we package with
the Directory Server.  It is also important to note that changes to
nsslapd-saslpath will not take effect until the Directory Server is restarted
since it needs to be used as part of the bootstrap config early during server
startup.
Comment 1 Nathan Kinder 2006-11-06 13:58:46 EST
Created attachment 140496 [details]
CVS Diffs
Comment 2 Noriko Hosoi 2006-11-06 14:24:06 EST
Looks good!  
Comment 3 Rich Megginson 2006-11-06 14:34:56 EST
I don't think this will work on 64 bit linux, because the default sasl path is
/usr/lib64/sasl2
Comment 4 Nathan Kinder 2006-11-06 14:35:07 EST
Created attachment 140499 [details]
CVS Commit Message

Checked into ldapserver (HEAD).  Thanks for the review Noriko!
Comment 5 Nathan Kinder 2006-11-06 15:04:48 EST
(In reply to comment #3)
> I don't think this will work on 64 bit linux, because the default sasl path is
> /usr/lib64/sasl2

Good catch.  The SASL_CB_GETPATH callback statues that the path returned is a
colon separated search path.  I'm thinking we should make the callback return
"usr/lib64/sasl2:/usr/lib/sasl2" if nsslapd-saslpath and SASL_PATH are not set.
 This should work with both 64-bit and 32-bit systems.
Comment 6 Rich Megginson 2006-11-06 15:33:24 EST
(In reply to comment #5)
> Good catch.  The SASL_CB_GETPATH callback statues that the path returned is a
> colon separated search path.  I'm thinking we should make the callback return
> "usr/lib64/sasl2:/usr/lib/sasl2" if nsslapd-saslpath and SASL_PATH are not set.
>  This should work with both 64-bit and 32-bit systems.

That would probably work, but it would be better if we could just skip the
getpath callback altogether on linux and just let the sasl library use its
configured path.
Comment 7 Nathan Kinder 2006-11-06 15:50:42 EST
(In reply to comment #6)
> That would probably work, but it would be better if we could just skip the
> getpath callback altogether on linux and just let the sasl library use its
> configured path.

We can do this, but the behavior will then be different across platforms.

There may also be some value in allowing the administrator to use a private SASL
plug-in directory in case they want to restrict ns-slapd to using a subset of
the mechanisms that they have installed on the system (perhaps they need
DIGEST-MD5 for some other non-LDAP application that uses SASL, but they only
want to allow GSSAPI SASL connections to their Directory Server).
Comment 8 Rich Megginson 2006-11-06 15:56:51 EST
(In reply to comment #7)

> There may also be some value in allowing the administrator to use a private SASL
> plug-in directory in case they want to restrict ns-slapd to using a subset of
> the mechanisms that they have installed on the system (perhaps they need
> DIGEST-MD5 for some other non-LDAP application that uses SASL, but they only
> want to allow GSSAPI SASL connections to their Directory Server).

Yep.  I think there is an enhancement request to that effect, or somehow allow
admins to turn off which SASL mechs the DS supports (e.g. allow them to edit
supportedSASLMechanisms, or use an ACI to hide them, etc.).

I guess the real way to do this would be to have configure determine what the
sasllibdir is and set it, and have that value passed down through make and
create_instance.  Then we could just use the same code for all platforms.
Comment 9 Nathan Kinder 2006-11-06 18:21:58 EST
Created attachment 140524 [details]
Additional CVS Diff

This additional set of diffs addresses the issue that Rich raised about 64-bit
Linux machines.  The fallback path in the SASL_CB_GETPATH callback is now
"/usr/lib64/sasl2:/usr/lib/sasl2".

Upon testing with this path, I noticed that it was possible to have the same
mechanism listed twice in the root DSE if it locates two plug-ins that
implement the same SASL mechanism.  This is possible with the old code as well
if you are using the SASL_PATH environment variable.  This seemed like a very
bad thing since the root DSE wouldn't even be a legal LDAP entry (essentially a
multi-valued attribute with a duplicate value).  To deal with this issue, I
extended the str2charray function so one could have it check for and remove
duplicates when creating the character array.
Comment 10 Nathan Kinder 2006-11-06 23:45:12 EST
Checked fixes from comment#9 into ldapserver (HEAD).  Thanks for the review Rich!

Checking in ldap/servers/slapd/charray.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/charray.c,v  <--  charray.c
new revision: 1.5; previous revision: 1.4
done
Checking in ldap/servers/slapd/saslbind.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/saslbind.c,v  <--  saslbind.c
new revision: 1.19; previous revision: 1.18
done
Checking in ldap/servers/slapd/slapi-private.h;
/cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-private.h,v  <--  slapi-private.h
new revision: 1.12; previous revision: 1.11
done

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