up to par with the Linux pam_access(8).
Like the Linux pam_access(8) our pam_login_access(8) is a service module
for pam(3) that allows a administrator to limit access from specified
remote hosts or terminals. Unlike the Linux pam_access, pam_login_access
is missing some features which are added by this commit:
Access file can now be specified. The default remains /etc/access.conf.
The syntax is consistent with Linux pam_access.
By default usernames are matched. If the username fails to match a match
against a group name is attempted. The new nodefgroup module option will
only match a username and no attempt to match a group name is made.
Group names must be specified in brackets, "()" when nodefgroup is
specified. Otherwise the old backward compatible behavior is used.
This is consistent with Linux pam_access.
A new field separator module option allows the replacement of the default
colon (:) with any other character. This facilitates potential future
specification of X displays. This is also consistent with Linux pam_access.
A new list separator module option to replace the default space/comma/tab
with another character. This too is consistent with Linux pam_access.
Linux pam_access options not implemented in this commit are the debug
and audit options. These will be implemented at a later date.
Reviewed by: bjk, bcr (for manpages)
Approved by: des (blanket, implicit)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D23198
match the primary group a user belongs to. This commit extends the
match to secondary groups a user belongs to as well, just as the Linux
pam_access(5) does.
Approved by: des (implicit, blanket)
as in the login.access(5) man page. However strcasecmp() is used to compare
for these special strings. Because of this User accounts and groups with
the corresponding lowercase names are misintrepreted to have special
whereas they should not.
This commit fixes this, conforming to the man page and to how the Linux
pam_access(8) handles these special words.
Approved by: des (implicit, blanket)
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
of the recent WARNS commits. The idea is:
1) FreeBSD id tags should follow vendor tags.
2) Vendor tags should not be compiled (though copyrights probably should).
3) There should be no blank line between including cdefs and __FBSDIF.