Hi Marcelo, On Thu, Aug 21, 2003 at 10:44:04AM +0200, Marcelo E. Magallon wrote: > 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?) In practice, what happens is that, libpam opens and reads both the service-specific config file and the fallback 'other' config file at startup; and then for each function call (pam_authenticate(), pam_acct_mgmt(), pam_open_session(), ...) it first looks to see whether there is a service-specific module list and if not, falls back to using the contents of /etc/pam.d/other. So if all services on the system should have exactly identical behavior when it comes to password changing, there's no need to specify any password lines in the service-specific configuration files: even if their configuration differs in other ways, everything will use /etc/pam.d/other for its decisions on making password changes. This is the rationale for the lack of a 'common-password' include. If someone can make a case that we ship a PAM-using service that needs its own policy for password changing, but would still benefit from referencing the common password policy, the common-password file can always be added later. > > - 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? The purpose of this current transition is to provide admins an easier way to change the default authentication configuration on their systems, without making any claims about the appropriateness of the current defaults. If you want all services to be subject to the constraints of pam_time, you can add it to common-auth. Since pam_time is primarily intended for tty-based services, it makes sense to me that it would only be listed in the config for the login service (and a few others). Given that it's commented out even in the default login config, I'm not sure it matters much either way from a packaging standpoint. And yes, login is a good example of a service where the includes (rather than a fallback) are needed. After conversion, /etc/pam.d/login, excluding comments, would look something like this: auth requisite pam_securetty.so auth requisite pam_nologin.so auth required pam_env.so @include common-auth @include common-account @include common-session session optional pam_lastlog.so session optional pam_motd.so session optional pam_mail.so standard noenv Cheers, -- Steve Langasek postmodern programmer
Attachment:
pgpEzpkTXxLvT.pgp
Description: PGP signature