copy the acquired TGT from the in-memory cache to the on-disk cache
at login. This was documented but un-implemented behavior.
MFC after: 1 week
PR: bin/64464
Reported and tested by: Eric van Gyzen <vangyzen at stat dot duke dot edu>
of releases. The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.
Approved by: re (scottl), markm
Discussed on: freebsd-current, in late April 2004
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.)
initialize the context. This way, a failure to initialize the context is
not fatal unless we actually have work to do - because if we don't, we
return PAM_SUCCESS without even trying to initialize the context.
pam_krb5 to consolidate the copyright texts. The semi-official
pam_krb5 module has been distributed with this new license text ever
since, but I'm just now getting around to updating the text here.
PAM module state (created in pam_sm_authenticate and referenced later
in pam_sm_setcred and pam_sm_acct_mgmt). However, the krb5_ccache
structure shares some data members with the krb5_context structure
that was used in its creation. Since a new krb5_context is created
and destroyed at each PAM entry point, this inevitably caused the
krb5_ccache structure to reference free'd memory.
Now instead of storing a pointer to the krb5_ccache structure,
we store the name of the cache (e.g. `MEMORY:0x123CACHE') in
pam_sm_authenticate, and resolve the name in the other entry points.
This bug was uncovered by phkmalloc's free'd memory scrubbing.
Approved by: re (jhb)
e.g.
Unknown error: -1765328378
we get
Client not found in Kerberos database
Another way to accomplish this would have been to leave
`error_message' alone, but to explicitly load the Kerberos com_err
error tables. However, I don't really like the idea of a PAM module
dorking with global tables.
Approved by: re (jhb)
- add __unused where appropriate
- PAM_RETURN -> return since OpenPAM already logs the return value.
- make PAM_LOG use openpam_log()
- make PAM_VERBOSE_ERROR use openpam_get_option() and check flags
for PAM_SILENT
- remove dummy functions since OpenPAM handles missing service
functions
- fix various warnings
Sponsored by: DARPA, NAI Labs
-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
makes FreeBSD inconsistent with previous releases and "other unices" as well
as with some internal password-asking services (e.g. ftp) within the same
release.
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.
