DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40075>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40075 ------- Additional Comments From [EMAIL PROTECTED] 2006-11-08 15:10 ------- The problem I see with this patch is around the value of req->dn when the function util_ldap_cache_getuserdn() fails. If ldap is unable to find a user object for a user name, obviously this function will fail and the actual value of "dn" that is returned from this function is undetermined (could be garbage). Yet if sec->require_dn is set to false, the code is allowed to continue as if it had a valid "dn" and "vals". Later when checking authorization for ldap-group, req->dn is passed back into util_ldap_cache_compare() which could end up causing a segfault. The other problem is that if other authorization types are used along side of ldap-group, req->dn would be reference within those checks as well which could segfault. Another issue is the addition of AuthLDAPGroupAttributeDN which is basically the same thing as AuthLDAPGroupAttribute except it sets an additional flag. Could you do the same thing by just referencing the flag that is already being set by AuthzLDAPRequireDN? AuthLDAPGruopAttributeDN doesn't seem very intuitive. I also might change AuthzLDAPRequireDN to something like AuthzLDAPRequireGroupDN but then that kind of conflicts with AuthLDAPGroupAttributeIsDN. I not sure how best to implement this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
