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

Re: SASL_MECH and useronly

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.