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. 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 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.
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 state Open to Feedback
first patch rejected, second patch may be acceptable (see discussion)