ldap group bug

[Dmitry Melekhov]

Hello!

OK, here is more correct patch- it restores bind to bind from config in  
lak_auth_bind


  diff -ur lak.c.orig lak.c
--- lak.c.orig    2013-06-07 09:15:20.098788278 +0400
+++ lak.c    2013-06-08 10:17:07.548233104 +0400
@@ -1448,8 +1448,25 @@
      if ( rc == LAK_OK &&
          (ISSET(lak->conf->group_dn) ||
           ISSET(lak->conf->group_filter)) )
-        rc = lak_group_member(lak, user, service, realm, dn->value);
+     {
+        /* restore config bind */
+                lak_unbind(lak);
+        rc = lak_user(
+        lak->conf->bind_dn,
+        lak->conf->id,
+        lak->conf->authz_id,
+        lak->conf->mech,
+        lak->conf->realm,
+        lak->conf->password,
+        &lu);
+        if (rc != LAK_OK)
+            goto done;
+        rc = lak_bind(lak, lu);
+        if (rc != LAK_OK)
+            goto done;

+        rc = lak_group_member(lak, user, service, realm, dn->value);
+       }
  done:;
      if (lu)
          lak_user_free(lu);


don't sure it is correct from leaking some resources though :-(


anyway it works ;-)



07.06.2013 21:23, Dmitry Melekhov пишет:
> 07.06.2013 20:19, Howard Chu пишет:
>> Dmitry Melekhov wrote:
>>> Hello!
>>>
>>> This bug exists in 2.1.26 , and, I guess , in previous versions.
>>>
>>> Problem is that after user is authentificated with ldap bind , ldap
>>> connection for checking user in group ( lak_group_member function )
>>> is made with this user's bind, not bind parameters from config file.
>>> User can not ( and have not in our case- I don't know why , but this is
>>> not real problem ) have access to ldap groups.
>>> And so, authentication is always fail.
>>>
>>> I added unbind and anonymous bind ( enough in our case):
>>
>> You have a major flaw in your directory server's access control 
>> configuration, if it has granted anonymous binds more privileges than 
>> authenticated binds.
>
> This is not flaw :-) This is just minor misconfiguration and nothing 
> more- really there is no impact on any real application.
> And, really. this is not my ldap server :-)
> But , anyway, this has no relation with real bug.
>
>>
>> No proper security system would ever do such a thing. Fix your access 
>> control configuration. This patch is wrong.
>
> I never said my patch is right, it just demonstrates where problem is.
> This is why I'm asking for right solution, i.e. access for groups info 
> with login from saslauthd config.
> Let's assume there is no access for authentificated user to groups 
> info, but there is access info in saslauthd config file which has.
> So , I think, this have to be fixed.
> Could you write right patch , which will do rebind not anonymously, 
> but with right access from config? :-)
> Thank you!
>
>
>>> /var/local/files/sasl/cyrus-sasl-2.1.26/saslauthd# diff -ur lak.c.orig
>>> lak.c
>>> --- lak.c.orig 2013-06-07 09:15:20.098788278 +0400
>>> +++ lak.c 2013-06-07 09:22:31.504774185 +0400
>>> @@ -1342,6 +1342,10 @@
>>> if (rc != LAK_OK)
>>> goto done;
>>>
>>> + lak_unbind (lak );
>>> + rc = lak_bind(lak, "");
>>> +
>>> +
>>> rc = ldap_search_st(lak->ld, group_search_base,
>>> lak->conf->group_scope, group_filter, (char **) group_attrs, 0,
>>> &(lak->conf->timeout), &res);
>>> switch (rc) {
>>> case LDAP_SUCCESS:
>>>
>>>
>>> but, it is obvoius that rebind should be done with credintials from
>>> config, but this is over my head :-(
>>>
>>> Could you, please, fix this bug correctly?
>>>
>>> Thank you!
>>>
>>>
>>
>>
>