> The current spec is in the case directory as proposal.txt and the
> updated pam_list(5) man page is in the materials directory. Both are
> attached here as well.
I wouldn't say I have an objection to this proposal, just a couple
questions and nits:
> SYNOPSIS
> pam_list.so.1
> DESCRIPTION
> The following options can be passed to the module:
>
> allow=
> The full pathname to a file of allowed users and/or netgroups.
> Only one of allow= or deny= may be specified.
>
> deny=
> The full pathaname to a file of denied users and/or netgroups.
> Only one of deny= or allow= may be specified.
>
> user
> The module should only perform netgroup matches on the username.
>
> nouser
> The username should not be used in the netgroup match.
>
> host
> Only the host should be used in netgroup matches.
>
> nohost
> The hostname should not be used in netgroup matches.
>
> user_host_exact
> The user and hostname must be in the same netgroup.
I believe an EXAMPLES section with the examples in the
proposal would help here.
> ATTRIBUTES
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ____________________________________________________________
> | ATTRIBUTE TYPE | ATTRIBUTE VALUE |
> |_____________________________|_____________________________|
> | Interface Stability | Evolving |
^^^^^^^^
Committed
> 1. Background
> -------------
> If you have complex netgroups and use them with passwd compat mode then
> there can be a noticeable and significant delay on every getpw*() call.
> This is due to the need to walk the netgroup to find the user, this is
> made worse because netgroups are not cached by nscd (but that is a
> story for another day).
Is this project still needed? Sparks is planned for the next
update release of S10. Shouldn't it handle the performance
issues noted here?
> 2. Proposal
> -----------
> This is deliberately a file on the local host rather than something
> held in LDAP against the user or host. There are other means for
> restricting authentication when pam_ldap is used, these based on the
> capabilities of the LDAP server and are sometimes specific to a given
> LDAP server.
I'm confused with what point is being made. LDAP is a name
service and can serve up name service requests such as
getpwent(), getnetrent(), ... pam_ldap(5) is a PAM service
module that coerces an LDAP style directory service into
an account authority.
But you know that, thus my confusion.
> There is also purposely no admin command, the customers requesting
> this functionality want a raw file as that is what they already use
> on Linux or on Solaris with the existing open source module.
IMO, this is an excuse for not providing a properly auditable
administrative interface and not a reason.
> 4. Examples
> -----------
See above re man page.
Gary..
