Date: Wed, 21 Feb 2007 12:16:04 -0800 From: Pete Rowley prowley@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.
In addition, LDAP is defined as it is in no small part to the underlying assumption of TCP and designed around the practical methods of authentication given that assumption, strictly speaking LDAPI isn't LDAP (it's not even platform agnostic), and LDAPI has other methods at its disposal.
And again, don't confuse the protocol with the transport. Fuzzy thinking like that is one of the reasons we have LDAP today, instead of just DAP over TCP. Sure the RFCs only define LDAP in terms of TCP, but obviously any reliable, ordered, stream transport will work just as well. And in a proper library implementation, such a transport can be substituted between any client and server without needing to alter any other code in the client or server.
While I understand your concern, the feature is an option, not a requirement.
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.
Yes, it's OK to provide options that completely change the behavior of the server. But it's only OK to do that *when the client explicitly asks for it*. I could define a control that causes all strings to be returned in Morse code, and that would be perfectly fine, because a client has to use the control before it gets such an outlandish behavior.
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...
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@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 wrote:
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...
Your if vendor code would be zero. Presumably Samba would be enabled with access in line with its operational requirements. Bearing in mind that Samba runs as root, it is likely to find that any machine it is installed on has anonymous access for root, just like it is allowed to actually run as root.
(In this vane, I so wish nsUniqueID was in standard GUID format, rather than %08x-%08x-%08x-%08x...)
I believe we have already discussed this and that I have already agreed that we would look at it.
On Thu, 2007-02-22 at 18:18 -0800, Pete Rowley wrote:
Andrew Bartlett wrote:
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...
Your if vendor code would be zero. Presumably Samba would be enabled with access in line with its operational requirements. Bearing in mind that Samba runs as root, it is likely to find that any machine it is installed on has anonymous access for root, just like it is allowed to actually run as root.
I'm not quite sure what you mean here, but what I don't want is a situation where the admin runs Samba4 against a Fedora DS instance, and forgets to explicitly set 'nsslapd-ldapiautobind: off'. Samba would end up proxying anonymous access as root!
It certainly seems an odd default.
Or worse still, there be a disagreement between applications as to if this is a setting they want, or a setting they don't want. Instead, have applications that want EXTERNAL auth ask for it, just as they have to ask for it for OpenLDAP.
Andrew Bartlett
Andrew Bartlett wrote:
On Thu, 2007-02-22 at 18:18 -0800, Pete Rowley wrote:
Andrew Bartlett wrote:
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...
Your if vendor code would be zero. Presumably Samba would be enabled with access in line with its operational requirements. Bearing in mind that Samba runs as root, it is likely to find that any machine it is installed on has anonymous access for root, just like it is allowed to actually run as root.
I'm not quite sure what you mean here,
I mean typically services are not allowed to run as root, but apparently Samba must so Samba is configured to do so if the site needs Samba. In exactly the same way, as an example only, auto bind for root might be often mapped to some administrative user in the directory, but clearly that would not be desirable if one wanted Samba to run on the machine. Options would then be: don't configure root as anything other than anonymous, or, if that was not acceptable, configure samba to use LDAP, not LDAPI, or configure samba to have root OS privilege, but make use of the autobind feature that allows to more finely distinguish between OS users with the same uid and have Samba identified by its own unique entry with its own unique security context. None of those options involve an #ifdef vendor or even the slightest whiff of a branch in your code.
It certainly seems an odd default.
Agreed, but that is moot at this point.
Howard Chu wrote:
Date: Wed, 21 Feb 2007 12:16:04 -0800 From: Pete Rowley prowley@redhat.com
Sorry, I don't mean to beat too much on a dead horse, but ...
;)
OK. That is a pretty powerful argument, and my rereading of the RFCs reveals that there is about zero wiggle room on this precise point. However, for us this is an experimental feature on top of an experimental feature (ldapi itself), and in that light I propose to do the following:
1. #ifdef WITH_AUTOBIND the auto bind code 2. not #define WITH_AUTOBIND 3. offer no configure mechanism for turning on autobind
This allows experimenters to do their experimenting but requires an unusual step (in an autotools world) on the part of builders to add the feature, and it will not appear in the binary builds of FDS offered for download.
Regards
389-devel@lists.fedoraproject.org
-
Andrew Bartlett -
Howard Chu -
Pete Rowley