ptclient & ldap changes

[Wesley Craig]

On 31 May 2008, at 17:25, Igor Brezac wrote:
> Wesley Craig wrote:
>> On 31 May 2008, at 00:06, Igor Brezac wrote:
>>> sasl used to be required for ldap proxy authz, but I do not think  
>>> this is the case any more.  I suggested that both ldap_sasl and  
>>> ldap_proxy_authz do the same thing.
>>
>> Perhaps I misunderstand you.  Since SASL authN and proxy authZ are  
>> more or less completely orthogonal, why would you have them do the  
>> same thing?  I propose that ldap_sasl control the way bind is  
>> done.  And ldap_proxy_authz is used to control how user DNs are  
>> obtained.
> Your patch breaks existing configurations, we usually try to  
> preserve configuration compatibility when possible.  Otherwise I am  
> fine with your approach.   Maybe automatically set ldap_proxy_authz  
> to true when ldap_sasl is turned on and when ldap_proxy_authz is  
> not explicitly specified in the config?

Well, that's an issue.  We could make ldap_proxy_authz tri-valued:  
legacy, on, and off.  Legacy would be the default and would revert to  
the old behavior.  Of course, that means that it wouldn't support  
imapd.conf's typical 0/1, on/off, t/f "switch" syntax.

> True, although it is broken when values of ldap_member_attribute  
> are represented with DN.  You are probably right, not worth messing  
> with.

I feel as tho if ldap_member_attribute is a DN, then maybe the proper  
scheme is ldap_member_method: filter.  Obviously, if the group entry  
doesn't have a reference to the members, that won't work.  But I  
think that jibes with my point the pt/ldap supports (more or less)  
two schemes for group membership.  Adding a variation on the (already  
kind of broken) ldap_member_method: attribute scheme which  
dereferences ldap_member_attribute's when they are DNs is a good  
feature.  Someone should need that feature, tho :)

>> LDAP_NO_LIMIT might be a useful way to handle this case, but  
>> you're still left wondering how to handle the case where the  
>> server's size limit is exceeded.  Do I populate what I got back?   
>> Do I populate nothing?
>
> I suppose LDAP_NO_LIMIT is lesser of two evils.  It seems  
> impractical for a user to be member of several hundred groups...

The complement is not true, tho: it's very practical in the  
ldap_member_method: attribute scheme for there to be a lot of users  
in a given group.  Perhaps the configurable size limit option should  
be removed.  If ldap_member_method is filter, there should be no  
(LDAP client imposed) size limit.  If ldap_member_method is  
attribute, the limit should be 1.

:wes