Re: Is it too late to try and generalize PAM for woody?
On 26 Jun 2001, Sam Hartman wrote:
> Anthony> If the
> Anthony> latter, can the versioned dep be added automatically, or
> Anthony> will we have a situation where some packages use the new
> Anthony> feature but don't depend on it properly?
> The dependency can be added by adjusting the shlibs file. For
> packages that use that mechanism (almost all) then the dependency
> would be automatic.
This also means that packages built on woody which do /not/ make use of the
new default configs will have an unnecessary versioned dependency.
Trade-offs... I have only 16 applications on my workstation that have placed
configs in /etc/pam.d, including all the X-related stuff. Am I naive to think
such a small number of developers would be able to communicate effectively
about PAM issues?
> Anthony> If you can't implement a smooth, automatic transition
> Anthony> (all old PAM programs continuing to work with the new PAM
> Anthony> stuff; a simple method to have PAM programs start using
> Anthony> the new method that's difficult to get wrong), it's
> Anthony> almost certainly best not to do this for woody. If you
> Anthony> can, it may still be better to upload the debs to
> Anthony> experimental until you've got them working. Once you've
> Anthony> got them working, it should be obvious whether there's
> Anthony> still time to get it in woody or not.
> Point taken. This was a good set of questions to focus thoughts on
> the issue; thanks.
My feeling is that it's worth getting the groundwork into woody, even if there
are no applications that will be using it. IIUC that this will be implemented
using the defined /etc/pam.d/other interface, I can't see how we would ever go
wrong by providing sane defaults in that file. The existing config from
potato/woody already attempts to do this.
Incidentally, I'd personally be wary of using alternatives for
/etc/pam.d/other; this makes it easy for a new authentication module to be
dropped in by cloning an existing config file, and it also makes it easy for
the config files to get out of sync on a system. If there are three packages
providing this alternative (libpam-modules, libpam-krb5, libpam-ldap), a bug
in the config means bugfixes to three different packages with three different
maintainers. Even in the absence of genuine config errors, having different
package versions on a system could lead to subtle differences in the behavior
between one auth scheme and another which slip through QA but which befuddle
and annoy system administrators. E.g., the administrator scratches his head
and wonders scowlingly why nologin is honored when using Unix authentication,
but it isn't when using Kerberos authentication...
Steve Langasek
postmodern programmer
Reply to: