[Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets)

[Andrew Bartlett]

On Thu, 2007-02-22 at 13:55 -0800, Howard Chu wrote:
> > Date: Wed, 21 Feb 2007 12:16:04 -0800
>  > From: Pete Rowley <prowley at redhat.com>
> 
> Sorry, I don't mean to beat too much on a dead horse, but ...
> 
> > Howard Chu wrote:
> >> > Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to 
> >> > request this privilege. There is no assumption of automagic 
> >> > authorization.
> 
> > I guess we can add that. Rich and I have already talked about that as a TBD.
> 
> > While observing RFC4513 is a good thing, and this implementation does so 
> > when auto-bind is switched off, I believe these kinds of decisions are 
> > the domain of site administrative policy and not of standards documents. 
> > Further, a client in the anonymous bind state has no practical knowledge 
> > of the effects of that state on server responses in any case, nor can it 
> > be sure that binding as a non-anonymous user has any effect on those 
> > responses, nor indeed does auto-bind necessarily remove or add any 
> > privilege for the client - that is all administrative policy and 
> > undefined by any RFC. This is just one more administrative policy option.
> 
> Certainly it's true that LDAP has nothing specific to say about 
> authorization. But don't confuse authorization with authentication; they're 
> two separate things. A client can easily determine that it's in an anonymous 
> state, using the WhoAmI extended op.
> 
> If "ldapwhoami -x -H ldapi:///" doesn't return a zero-length ID, then your 
> server is broken.

Agreed.  Now I should implement that extended operation in our server
some day...

> Yes, but it shouldn't be an option at all. You provide the option in the 
> expectation that someone will use it. The presence of such an option 
> therefore encourages client writers to depend on non-standard behaviors. You 
> might say "this is a site-local policy decision" but it doesn't just affect a 
> single site. You implicitly create lock-in with features like this, and you 
> have no idea what other servers such clients will eventually be talking to.
> I would expect thinking like this from Microsoft or Sun, but not from an open 
> source developer. And no matter how much we may think our respective server 
> is the best in the world, and that no one would ever have any reason to talk 
> to any other server, one need only look at SunOne to see that nothing lasts 
> forever. Providing options that break standards like this *hurts* your users, 
> it doesn't help them.
> 
> The standard mechanism for using an LDAP session with previously established 
> credentials is to use a SASL/EXTERNAL Bind. Encouraging any other behavior is 
> flat out wrong.

> Some folks may be wondering why I'm spending so much time on this point, 
> since it's your server and I'm not contributing to its code. Just remember 
> that network protocols are about interoperability; nothing you do exists in a 
> vacuum. Every mistake anyone makes affects everyone - just look at the 
> dynamic group mess if you need an example...

I strongly agree with Howard on this one.  I want Samba to be able to
bind to either OpenLDAP or Fedora DS and have as few differences as
possible.  

And where OpenLDAP has done something first, or it's way of doing things
is more sane, I ask that Fedora DS follow that lead.  I need less, not
more 'if <vendor>' code...

(In this vane, I so wish nsUniqueID was in standard GUID format, rather
than %08x-%08x-%08x-%08x...)

If this needs to be made easier for client apps, then work on making
setting up ldapi:// connections with an EXTERNAL bind trivial to do from
the Perl Net::LDAP module and python.  That will help users, no matter
the LDAP server they choose to deploy. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20070223/c9b53451/attachment.sig>