Re: Transition: new PAM config file handling in unstable

["Marcelo E. Magallon" <mmagallo@debian.org>]

Hi Steve,

 thanks for the work.  A couple of questions for clarity's sake (as
 sysadmin, not packager)

On Wed, Aug 20, 2003 at 10:37:59PM -0500, Steve Langasek wrote:

 > - Per-package /etc/pam.d/ configuration files should not include
 >   explicit 'password' blocks.  Instead, services should use the builtin
 >   libpam fallback to /etc/pam.d/other for their password changing
 >   policy.

 Does this mean that "other" is read even if "service" exists?  From the
 docs:

        There is a special service-name, reserved for defining a default
        authentication mechanism. It has the name `OTHER' and may be
        specified in either lower or upper case characters. Note, when
        there is a module specified for a named service, the `OTHER'
        entries are ignored.

 It doesn't mention password specifically, so I don't quite understand
 why password falls back to other while the other module-types need an
 extra include file (or the other way around: why doesn't password have
 an include file, too?)

 > - Configuration files should be modified to no longer reference
 >   pam_unix directly.  For auth, account, and session blocks, such
 >   references should be replaced with these lines:
 >     @include common-auth
 >     @include common-account
 >     @include common-session
 >   These @include lines are handled as literal includes by libpam, so
 >   packages that currently use other modules besides pam_unix (or offer
 >   commented-out examples) need only leave those surrounding module lines
 >   intact.

 You mean something like login's use of e.g. pam_motd?  Should pam_time
 be in common-account or in login's own file?  Rationale?

-- 
Marcelo