--pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 15, 2002 at 10:03:27AM +1000, Martin Schwenke wrote: > >>>>> "Steve" =3D=3D Steve Langasek <vorlon@netexpress.net> writes: >=20 > Steve> And the 'A' and the 'M' say 'authentication modules', which > Steve> succinctly defines the scope of PAM. Retrieving group > Steve> lists is not an authentication problem. > OK, fair enough... However, a lot of the session management stuff has > nothing to do with authentication either: > session optional pam_motd.so # [1] > session optional pam_mail.so standard noenv # [1] > session required pam_limits.so > pam_limits is closer to initgroups than it is to authentication! > Since session management has always been part of PAM, I think it might > be a case of finding a cute acronym that fits pretty well... :-) Certainly, there are things outside of pure authentication that PAM is able to handle, and that's to everyone's advantage; but you can only stretch this particular API so far. Several other respondents have discussed the need for a strong kernel credential API, and I agree that this is where improvements need to start. What you're asking for calls for a new API, not modifications to an existing, stable one. > Steve> Easily done: > Steve> auth sufficient pam_unix.so > Steve> auth required pam_ldap.so use_first_pass > Steve> -- and that's it. If the account is local, pam_ldap will neve= r be > Steve> invoked with the above configuration. Likewise, list > Steve> 'files' before 'ldap' in nsswitch.conf, to give optimal > Steve> lookup times for getpwnam()/getgrgid() calls on local > Steve> accounts. > However, I started this thread using almost exactly the same example, > except for account modules. That doesn't work... :-( IIRC, pam_ldap should not be invoked in the above for any accounts that successfully authenticate using pam_unix. At the very least, Linux-PAM makes it possible to ensure pam_ldap is not invoked, via its extended=20 configuration syntax. auth [success=3Ddone default=3Dignore] pam_unix.so auth required pam_ldap.so use_first_pass This guarantees that pam_ldap will not be invoked if pam_unix succeeds. > Steve> The one slowdown will be with initgroups() (yes, I meant > Steve> initgroups() earlier, not getgroups()). There's no way > Steve> around that; you can lower your timeouts in nss_ldap, or > Steve> you can modify your login app to not call initgroups(). > ... except that the pam_unix account management does NSS calls... pam_unix calls getpwnam(), getspnam(), endpwent(), endspent(), setpwent(), and setspent(). It makes no group-related calls at all, and the NSS calls it does make MUST also work for local users /outside/ of a PAM context as well if the app is to be able to successfully log the user in. > Steve> Those are your only two options, unless you do choose to > Steve> modify the PAM API; and there would have to be a very good > Steve> reason for Linux-PAM to break compatibility with other PAM > Steve> implementations. > True. I believe that FreeBSD is running its own PAM implementation, > but I don't know if the API has changed... Not that I'm aware of. Steve Langasek postmodern programmer --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE84y/MKN6ufymYLloRArYVAJwKAbG//u+2ot/GX+XrdBho4TGgCACeMDyH 3lmr7+DxulmBg9RO47wnK0g= =hEHM -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/--
