pam_nologin(8) starts to provide an account management function in
addition to the existing authentication function so that sshd(8) can
respect nologin(5) while the rest of PAM consumers work as earlier.
In turn, sshd(8) starts to use the new account management function
in pam_nologin(8) and thus respect nologin(5) even when doing public
key authentication with sshd's internal routines (PAM authentication
isn't called at all in that case).
Based on:
1.12 +2 -10 src/lib/libpam/modules/pam_nologin/pam_nologin.c
1.6 +10 -11 src/lib/libpam/modules/pam_nologin/pam_nologin.8
1.16 +1 -1 src/etc/pam.d/sshd
Approved by: des
PR: bin/112574
Use the current user's login class for the decisions about where
the nologin(5) file is located and whether the user may bypass its
restriction.
Add some error checks.
Revision Changes Path
1.7 +16 -15 src/lib/libpam/modules/pam_nologin/pam_nologin.8
1.13 +42 -29 src/lib/libpam/modules/pam_nologin/pam_nologin.c
Note: To avoid POLA violation, the merged module still lets root
in irrespective of login.conf settings. In HEAD, root has to have
an explicit "ignorenologin" capability to bypass nologin(5).
PR: bin/107612
pam_unix.c 1.52
pam_unix.8 1.13
In account management, verify whether the account has been locked
with `pw lock', so that it's impossible to log into a locked account
using an alternative authentication mechanism, such as an ssh key.
This change affects only accounts locked with pw(8), i.e., having a
`*LOCKED*' prefix in their password hash field, so people still can
use a different pattern to disable password authentication only.
Mention all account management criteria in the manpage.
PR: bin/71147
Some years ago handling login.access(5) was moved from login(1) to
pam_login_access(8) completely and unconditionally. This patch is
to finalize the move by deleting unused files and defines, and by
updating the manpages. In addition, login.access.5 will be installed
from the pam_login_access src directory, to where it belongs and
where it has lived for quite a while, too.
Besides satisfying general purism, this patch should stop ongoing
attempts to fix the dead code.
Approved by: re (mux)
When (re)allocating space for an array of pointers to char, use
sizeof(*list), not sizeof(**list). (i.e., sizeof(pointer) rather than
sizeof(char)).
Approved by: re (scottl)
if _FREEFALL_CONFIG is set gcc bails since pam_sm_setcred() in pam_krb5.c
no longer uses any of its parameters.
Pointy hat: kensmith
Approved by: re (scottl)
branches but missed HEAD. This patch extends his a little bit,
setting it up via the Makefiles so that adding _FREEFALL_CONFIG
to /etc/make.conf is the only thing needed to cluster-ize things
(current setup also requires overriding CFLAGS).
From Peter's commit to the RELENG_* branches:
> Add the freebsd.org custer's source modifications under #ifdefs to aid
> keeping things in sync. For ksu:
> * install suid-root by default
> * don't fall back to asking for a unix password (ie: be pure kerberos)
> * allow custom user instances for things like www and not just root
The Makefile tweaks will be MFC-ed, the rest is already done.
MFC after: 3 days
Approved by: re (dwhite)
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>
If turned on no NIS support and related programs will be built.
Lost parts rediscovered by: Danny Braniss <danny at cs.huji.ac.il>
PR: bin/68303
No objections: des, gshapiro, nectar
Reviewed by: ru
Approved by: rwatson (mentor)
MFC after: 2 weeks
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
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
Tested on: i386 sparc64
These files had tags after the copyright notice,
inside the comment block (incorrect, removed),
and outside the comment block (correct).
Approved by: rwatson (mentor)
