I put the wrong email address in the document.  It should be 
dbroady1@aol.com.  An alternative is   dbroady@lexmark.com

Darin Broady

At 08:18 AM 1/9/2004, dsbroa0@aol.com wrote:
>Full_Name: Darin Broady
>Version: 2.2.4
>OS: Irix 6.5.19m & Solaris 8
>URL: ftp://ftp.openldap.org/incoming/DarinBroady-040109.patch
>Submission from: (NULL) (192.146.101.11)
>
>
>I have written a PreBind plugin that will allow us to use native Solaris LDAP
>pam_ldap with our OpenLDAP server.  Everything was going well until I put in an
>ACL that denied access to the server through the following:
>
>access to dn.exact="cn=testing,o=dept,c=us" attrs=userPassword
>     by * none
>
>With my PreBind plugin disabled (ie. not loaded into the executable), I found
>that this ACL worked as I expected.  However, with my PreBind plugin included, I
>found that this ACL was not being adhered to.  Knowing that this was a access
>problem, I looked through the SLAPI API to find out if there was a function that
>I could use to test AUTH access to the userPassword attribute.  I found the
>slapi_access_allowed function, but it only gives the ability to look at compare,
>search, read,& write access.

As SLAPI follows the Netscape access model, you just call slapi_access_allowed()
for compare.  (Maybe slapi_access_allowed() could be modified to map compare
to auth when called from a bind operation, but not knowing SLAPI internals, I'll
leave that to someone else to consider.)

>I could not find a function in the SLAPI API that
>allows a plugin to check for AUTH access, which means that a PreBind plugin can
>inadvertently subvert the ACLs.
>
>I have a small patch can a fix it.  What it does is make an AUTH-test call to
>access_allowed() on the userPassword attribute of the DN binding just before the
>PRE_BIND plugins are called.

This is inappropriate.  slapd(8) shouldn't do much before a pre-operation
plugin.  (It's called pre- because it comes before slapd(8) does it work.)

Also, I note, the assumption that the password is held in userPassword is
flawed.

>This should make it so that all PRE_BIND plugins
>can not subvert the ACLs, at least for the userPassword attribute.  I have
>tested the patch and it works great for us.

changed notes

moved from Incoming to Software Bugs

Kurt,

Thanks for your response.  One question:  When isn't the password for a
user not in some way stored in the userPassword attribute?

Also, if changing the slap_access_allowed() function is appropriate, then
here is a patch that would do what we need.  Let me know what you think of
this patch.

One final thing.  In my original posting of the problem, I entered the
wrong email address.  Would you please change it to   dbroady1@aol.com
instead of  dsbroa0@aol.com?  Thanks.


--- slapi_utils.c.orig  Wed Jan 14 09:39:25 2004
+++ slapi_utils.c Wed Jan 14 09:47:09 2004
@@ -3256,9 +3256,16 @@
            return ret;
      }

+     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
+           return LDAP_PARAM_ERROR;
+     }
+
      switch ( access & SLAPI_ACL_ALL ) {
      case SLAPI_ACL_COMPARE:
-           slap_access = ACL_COMPARE;
+           if (op && op->o_tag == LDAP_REQ_BIND)
+                 slap_access = ACL_AUTH | ACL_COMPARE;
+           else
+                 slap_access = ACL_COMPARE;
            break;
      case SLAPI_ACL_SEARCH:
            slap_access = ACL_SEARCH;
@@ -3282,10 +3289,6 @@
      }

      if ( slapi_pblock_get( pb, SLAPI_CONNECTION, (void *)&conn ) != 0 ) {
-           return LDAP_PARAM_ERROR;
-     }
-
-     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
            return LDAP_PARAM_ERROR;
      }



Darin Broady
dbroady@lexmark.com
Lexmark International, Inc.

At 07:18 AM 1/14/2004, dbroady@lexmark.com wrote:
>Kurt,
>
>Thanks for your response.  One question:  When isn't the password for a
>user not in some way stored in the userPassword attribute?

A backend could, for instance, implement the authPassword, the
unicodePwd, or other other password attribute.  Or the backend
could use an external password store.

>Also, if changing the slap_access_allowed() function is appropriate, then
>here is a patch that would do what we need.  Let me know what you think of
>this patch.

This patch seems more suitable.  However, I'll defer any action
regarding it to a committer with more experience with SLAPI.

>One final thing.  In my original posting of the problem, I entered the
>wrong email address.  Would you please change it to   dbroady1@aol.com
>instead of  dsbroa0@aol.com?  Thanks.
>
>
>--- slapi_utils.c.orig  Wed Jan 14 09:39:25 2004
>+++ slapi_utils.c Wed Jan 14 09:47:09 2004
>@@ -3256,9 +3256,16 @@
>            return ret;
>      }
>
>+     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
>+           return LDAP_PARAM_ERROR;
>+     }
>+
>      switch ( access & SLAPI_ACL_ALL ) {
>      case SLAPI_ACL_COMPARE:
>-           slap_access = ACL_COMPARE;
>+           if (op && op->o_tag == LDAP_REQ_BIND)
>+                 slap_access = ACL_AUTH | ACL_COMPARE;
>+           else
>+                 slap_access = ACL_COMPARE;
>            break;
>      case SLAPI_ACL_SEARCH:
>            slap_access = ACL_SEARCH;
>@@ -3282,10 +3289,6 @@
>      }
>
>      if ( slapi_pblock_get( pb, SLAPI_CONNECTION, (void *)&conn ) != 0 ) {
>-           return LDAP_PARAM_ERROR;
>-     }
>-
>-     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
>            return LDAP_PARAM_ERROR;
>      }
>
>
>
>Darin Broady
>dbroady@lexmark.com
>Lexmark International, Inc.

moved from Software Bugs to Contrib

changed notes

changed notes

changed state Open to Feedback

first patch rejected, second patch may be acceptable (see discussion)