Re: Is it too late to try and generalize PAM for woody?

[Sam Hartman <hartmans@debian.org>]

>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:

    Anthony> On Mon, Jun 25, 2001 at 07:03:11PM -0400, Sam Hartman
    Anthony> wrote:
    >> I'm mainly asking for political/time objections to trying to
    >> start implementing this, not technical objections on how it
    >> should be implemented at this point.

    Anthony> What exactly would the transition plan be?

The features would be added to libpam.  The pam package would start
including files for the default authentication/account stack.  I'm not
sure that including a default session stack would be sufficiently well
defined.  A default password stack would also be included.

I'd get with maintainers of packages like login, ssh and xscreensaver
and try and get them to adopt including the default stacks rather than
explicitly stating the pam modules to use.  Later I might try and add
a mechanism for modules like libpam-heimdal or libpam-ldap to ask the
user if they want to set up a new authentication strategy for the
machine.  If the user said yes, then the module would update the
default configuration file, using some mechanism (alternatives springs
to mind as an obvious candidate, although I want to consider possible
situations that could leave the system with no configuration at all
before actually accepting alternatives).


    Anthony> Will you just upload a new pam package that'll work with
    Anthony> all the old debs from potato and anything currently in
    Anthony> woody or sid? 

Yes, that would be the plan.  If I find anything that would prevent
things from working with existing PAM applications and service
modules, I would consider that a show stopper for the project.


    Anthony> Will anything users have done break? 

When users install new application packages they would be given the
standard dpkg configuration file changed prompt if they had changed
things.  If the user elected not to install the new configuration
files then the user would not notice the change.  If the user elected
to install an inconsistent set of configuration files (keeping some
modified files, installing some new files), then the user might have a
system that didn't work very well.  Depending on which strategy is
selected, the set of inconsistent configuration files might be the
empty set.


    Anthony> Can
    Anthony> you implement the changes without causing bugs?

Now,  that's a good question;)

I believe so, or at least I believe that as I start to implement
changes I can evaluate risk reasonably.  The PAM configuration files
are only writable by root, so buffer overflows and similar problems
are not much of an issue.  I believe I'm capable of writing secure
code even when untrusted input is involved, but the risks of such code
are naturally greater than code running entirely within one privilege
domain.


    Anthony> If you get PAM changed, and someone uploads a package
    Anthony> using the new features, what will break? 
Ideally nothing.

    Anthony> Will such
    Anthony> packages work with an old pam that doesn't handle the new
    Anthony> features or will it need a versioned dependency? 
A versioned dependency on libpam0g will be required.

    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.


that 
    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.