At 01:33 PM 1/11/2006, Luke Howard wrote: >>I think the reason was that setting this globally will >>prevent individual users from taking advantage of the >>full function of programs. For instance, (IIRC) >>if the user wants to auto-select the mechanism, having >>SASL_MECH set globally will disallow this. > >Well, feel free to back out the patch. It seems to me, >though, that if the administrator wants to force the >use of a specific set of SASL mechanisms, they should >be able to.
Note that users can tell the library to use an alternative ldap.conf(5) file, and hence go around any 'policy' the administrator tries to enforce using ldap.conf(5). The administrator should use more appropriate means for enforcing such policy, such as properly configuring their server to support the particular set of allowed mechanisms. (Administrators could also only install Cyrus SASL plugins for these mechanisms, but that won't prevent a user from using LDAP clients that uses these mechanisms via a private SASL install.) The intent was for ldap.conf(5) to provide defaults values for command line arguments. These defaults were only to be used when the user of the tool did not provide a value via the command line. That is, the user should always be able to specify the desired behavior explicitly on the command line such that any and all defaults values are ignored. There is a growing problem that a number of values (such as TLS configuration details) can only be provided via ldap.conf(5)/.ldaprc. I consider each instance of this to be a bug. Kurt
