on the release media -- only put what is different in the crypto
version compared to the base version. This reduces PAM entries
in /usr/lib in the "crypto" distribution to:
libpam.a
libpam.so@
libpam.so.2
pam_krb5.so@
pam_krb5.so.2
pam_ksu.so@
pam_ksu.so.2
pam_ssh.so@
pam_ssh.so.2
The libpam.so* is still redundant (it is identical to the "base"
version), but we can't set DISTRIBUTION differently for libpam.a
and libpam.so.
(The removal of libpam.so* from the crypto distribution could be
addressed by the release/scripts/crypto-make.sh script, but then
we'd also need to remove redundant PAM headers, and I'm not sure
this is worth a hassle.)
-lroken is an installable library, there's no need to give an
explicit path to it. In any case, -L paths should be specified
in LDFLAGS if needed.
Approved by: des
applications linked with Linux-PAM will still work.
Remove pam_get_pass(); OpenPAM has pam_get_authtok().
Remove pam_prompt(); OpenPAM has pam_{,v}{error,info,prompt}().
Remove pam_set_item(3) man page as OpenPAM has its own.
Sponsored by: DARPA, NAI Labs
Move common stuff into Makefile.inc, and tidy up all the Makefiles
as a result.
Build new modules.
Put a commented-out dependancy on libpam for the (shared) modules.
I can't bring this in just yet, as the dependancy (modules->libpam)
is reversed for the static case (libpam->modules).
pam_krb5 is a Kerberos 5 (Heimdal) authentication module.
pam_nologin checks for /etc/nologin and does the "usual stuff"
if it is found, otherwise it silently succeeds.
pam_rootok silently succeeds if the user is root, otherwise
it fails.
pam_wheel silently succeeds if the user is a member of group
"wheel" (or another nominated group), and fails
otherwise.
There is an issue with kerberosIV and kerberos5 - if both are
being built, then static linking fails with duplicate symbols.
This will take a bit of work to sort out in the kerberii.
