| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
mailbox protocols. Add pam_unix to the `account' function class, too,
for imap and pop3 to actually implement this policy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of an authentication function. There are a design reason
and a practical reason for that. First, the module belongs in
account management because it checks availability of the account
and does no authentication. Second, there are existing and potential
PAM consumers that skip PAM authentication for good or for bad.
E.g., sshd(8) just prefers internal routines for public key auth;
OTOH, cron(8) and atrun(8) do implicit authentication when running
a job on behalf of its owner, so their inability to use PAM auth
is fundamental, but they can benefit from PAM account management.
Document this change in the manpage.
Modify /etc/pam.d files accordingly, so that pam_nologin.so is listed
under the "account" function class.
Bump __FreeBSD_version (mostly for ports, as this change should be
invisible to C code outside pam_nologin.)
PR: bin/112574
Approved by: des, re
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
users who don't wish to use it. If the admin is worried about leaking
information about which users exist and which have OPIE enabled, the
no_fake_prompts option can simply be removed.
Also insert the appropriate pam_opieaccess lines after pam_opie to break
the chain in case the user is logging in from an untrusted host, or has a
.opiealways file. The entire opieaccess / opiealways concept is slightly
unpammish, but admins familiar with OPIE will expect it to work.
Reviewed by: ache, markm
Sponsored by: DARPA, NAI Labs
|
| |
|
|
|
|
|
| |
conversion script generated the wrong format, so the configuration files
didn't actually work. Good thing I hadn't thrown the switch yet...
Sponsored by: DARPA, NAI Labs (but the f***ups are all mine)
|
|
|
Sponsored by: DARPA, NAI Labs
|
