On Wed, Oct 26, 2011 at 09:17:17PM +0300, Nerijus Kislauskas wrote:
> On 10/26/2011 08:11 PM, Viktor Dukhovni wrote:
> > The LDAP table driver considers entries that match the query filter,
> > but which lack the requested attributes, or have only empty values
> > for the requested attributes to not be matching attributes. The Postfix
> > dictionary abstraction above the Postfix LDAP driver therefore only sees
> > entries with non-empty result (or leaf or terminal) attributes.
>
> Hi Victor and others,
>
> So in other words you want to say, that "our implementation of ldap
> lookup table is strongly tied to LDAP ACLs.
Nothing of the sort, in fact LDAP ACLs typically easily hide the entries
themselves not just the attributes, since otherwise I can discover the
attribute quickly by alphabetic search:
(&(attribute=a*)...)
(&(attribute=b*)...)
(&(attribute=c*)...) ... Until match, then
(&(attribute=ca*)...)
(&(attribute=cb*)...)
(&(attribute=cc*)...)
(&(attribute=cd*)...) ... Until match, ...
This does not take very long...
> When I have enough rights
> to read something from LDAP, entry exists, and when my drunk LDAP admin
> thinks, that I have too much rights, lookup will fail, even when I got 1
> entry match".
Nonsense, you are the mercy of your drunk LDAP admin when you choose to
use LDAP. The admin can also delete all the entries, hide a sub-tree, ...
> Wake up guys.
Lose the attitude or go away. You're new here, it rather presumptuous
to start lecturing people who've been here for 10+ years.
The Postfix LDAP driver does not know
whether the result is wanted or not, that's much higher up in the
stack. Its job is to retrieve results, and there are no results to
return when the attribute is missing, in fact this is desirable
when groups contain members with no email address for reasons
unrelated to email, ...
The treatment of empty attribute values was chosen to be least
surprising to most users where blank and missing work interchangeably,
rather than Postfix returning configuration errors and warnings
about bad table results.
--
Viktor.
