/etc/sasl

[Patrick Ben Koetter]

* Russ Allbery <rra at debian.org>:
> Fabian Fagerholm <fabbe at paniq.net> writes:
> > On Fri, 2008-01-11 at 23:40 +0100, Patrick Ben Koetter wrote:
> 
> >> IIRC RedHat already ships RHEL 5.1 with /etc/sasl2. We'll see how this
> >> ends.  Having configuration in /usr/lib/sasl2, /usr/lib64/sasl2 (I've
> >> seen that too) or /var/lib/sasl2 (Mandriva?) or associated with an
> >> applications configuration directory is IMHO not the way any UNIX
> >> system leaning towards FHS should do it.
> 
> >> I personally think /etc/sasl is a good place.
> >
> > /etc/sasl2 would be more symmetrical with the other sasl* commands and
> > files. I think Ross' idea of creating the directory and placing a README
> > file in it is not bad at all.
> >
> > We could then encourage other package maintainers to place default SASL
> > configuration files for their programs in that directory.
> >
> > Opinions?
> 
> Currently, OpenLDAP puts its SASL configuration in /etc/ldap, which from
> the OpenLDAP perspective also makes sense.  I personally think of SASL

The OpenLDAP source code does this by default or is this Debian specific? I am
used to have it in /usr/lib/sasl2/slapd.conf. Having it in
/etc/ldap/slapd.conf would collide with the slapd configuration file
slapd.conf (presuming one is not using /etc/ldap/slapd.d/ to have all config
changeable at runtime).


> configuration as more of an application configuration than a system-wide
> configuration thing.  In other words, it doesn't feel like PAM as much as
> it feels like the internals of the particular application.  This is helped
> along by SASL's support for configuration hooks so that an application can
> embed the SASL configuration directly inside its own normal configuration
> mechanism.

Well, yes. Maybe its because SASL config files are scattered all over the
system that I am so in favor of a single location.


> It seems like the argument for putting all the SASL configuration in a
> central directory would be if multiple packages were sharing the same
> configuration (similar to PAM's common-auth files).  Is that the situation
> that we expect?

Honestly, no. AFAIK the application_name sent by the server seeking
authentication services from libsasl determines the name of the file libsasl
will search for in the configuration directory.

I do know the path to the config file can be changed as well when libsasl is
being initialized. That's the way Debian Postfix does it at the moment if I am
right.

What might speak for having it all in one location is that people need to set
SASL up separately from their app and that they also (should) test it
separately from their app. It's more like a standalone thing. I can set it up
and have it working without even having e.g. Postfix installed.

> (Regardless, I agree that /usr/lib/sasl2 is a bad location for any
> configuration files of any kind, and in my ideal world the Debian packages
> wouldn't look there at all.)

ACK. But having SASL config close to the particular application will always be
possible. If a developer/maintainer chooses to change the default path they
will always override the defaults.

The question probably is: What do we want to be the default?

How about this for a migration path from /usr/lib/sasl2 to /etc/sasl2:

1. Search in app specific path (controlled by app maintainer/developer)
2. Search in /etc/sasl2 (controlled by SASL defaults)
3. Search in /usr/lib/sasl2 and log a warning that /usr/lib/sasl2 is being
   deprecated.

p at rick