Mike Gerdts wrote: > On 2/23/07, Darren J Moffat <Darren.Moffat at sun.com> wrote: >> DESCRIPTION >> pam_list module implements pam_sm_acct_mgmt(), which >> provides functionality to the PAM account management stack. >> The module provides functions to validate that the user's >> account is valid on this host based on a list of users and/or >> netgroups in the given file. > > There should be some hint in the man page that netgroups start with @. > >> The username is the value of PAM_USER. The host is the value of >> PAM_RHOST or if PAM_RHOST is NOT set then the value of the localhost >> as returned by gethostname(3c) is used. > > Would it be feasible to extend the functionality to allow address > ranges, either in the form of bare IP addresses, IP ranges > (192.168.200.0 - 1192.168.200.37), or net/mask (192.168.1.0/24, > 192.168.4.0/255.255.252.0)?
Possible yes, but in this particular project case no I'm not willing to add that complexity. > At best, PAM_RHOST would be difficult to use here (e.g. getpeeraddr() > returned a hostname that resolves to multiple IP addresses). Can you > still do a getpeeraddr() by the time that the PAM stack is being > processed? You can't use getpeeraddr() inside a PAM module because it doesn't have access to the file descriptor that represents the peer. >> user_host_exact >> The user and hostname must be in the same netgroup. > > Could this also mean user at host? For the few cases where I need > telnet/ftp/rsh enabled, it is not worth the trouble of a netgroup. > user at host would make the administration much easier. We will consider user at host for a future case, but not this one. > A test program to verify configuration would be extremely helpful. > Currently, as I abuse compat, I can do "getent passwd [username]" to > get a pretty good idea who has access to a system. This module would > break that functionality. A test program would likely be along the > lines of: Not as part of this case. -- Darren J Moffat
