[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE

At 01:37 AM 11/19/2006, michael@stroeder.com wrote:
>Full_Name: Michael Ströder
>Version: not relevant
>OS: not relevant
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (
>I'd like to see support for RFC 3045 in slapd.

The only reasonably decent use of such attributes is for
administrators to determine whether they need to upgrade
some software or not (though use of a protocol attribute
for this purpose is somewhat problematic).  We provide
cn=monitor for this purpose.

The primary use (or I should say misuse) of such strings
is for server behavior discovery (whether the behavior
is due to a feature or a bug).  As this use leads to
interoperability problems (as illustrated by the HTTP
"mozilla" compatibility problems), we must allow
spoofing and should discourage this use.  We support
the former via the rootdse configuration option.
We support the latter by not providing any values by

While it certainly is possible for a client to abuse
cn=monitor version information, the very fact that the
version information is in cn=monitor, which generally
requires special authorization to read, instead of
the root dse, which generally is readable by most
every client, is effective in discouraging this abuse.
I think it reasonable to assume any administrative tool
for determining whether an OpenLDAP server is up to date
would have appropriate authorization to read the
cn=monitor values.

I note that such tools should not assume a server
needs not be upgraded simply because the version is high
enough.  There easily could be dependent software whose
version is not high enough.  It would be good for
cn=monitor to not only expose the OpenLDAP version
information, but to expose version information for
dependent software.  Of course, as there is an endless
number of dependent software, this upgrade detection
approach problematic.  Seems it would be better to
use tools that ran directly on the box to determine
whether a server's software needed to be upgraded.
But I digresss.

In the past we have rejected submissions to extend
slapd(8) to generate these values, hence I think this
feature request should be closed.

However, such closure certainly doesn't preclude someone
from implementing **additional** vendorName/Version functionality
and submitting it for consideration.  There is one aspect of our
current vendorName/Version support that is lacking is in dealing
with multiple broken clients requiring different 
vendorName/Version strings.  An overlay which spoofed these
strings on a configurable basis, whether by authorization
identity and/or IP address and/or other authorization factor,
would be an interesting functionality addition.