On Jun 13, 11:14am, Dan Melomedman wrote:
} John Nemeth wrote:
} >      There has been much criticism about PAM not being ideal.  However,
} > we all know about other solutions that aren't ideal, but which must be
} > included if NetBSD is to be considered to be a player in the OS game
} > (i.e.  NFS).  PAM is currently used by FreeBSD, HP-UX, most Linux
} > systems, and Solaris.  It is also used by many third party apps that
} > need to perform authentication.  It is the only standarised way of
} > having flexible authentication.  For these reasons, I believe PAM is
} 
} The famous saying goes "The problem with standards is there are so
} many". It's a standard depending who you ask. If PAM is the only way
} of having flexible authentication, then NFS (Network Failure System) 
} is also the only way to share files.

     I didn't say it is the only way.  Obviously, there are other ways,
such as BSD auth.  However, it is the only standardised way that I know
about and it is in widespread use.  This last point is very critical.

} How about then, adding a better framework for authentication additional
} to PAM (and maybe even standardizing on it, having PAM for

     I have no problem with this.  This is really orthoganal to
implementing PAM.  There can be as many authentication methods as there
are willing developers and that core is willing to support.  I am
primarily interested in PAM because of its prevalence.

} interoperability with other OSes)? Something simpler in design, API and
} ease  of use. Who knows, maybe in a few years the NetBSD's framework will
} be accepted by others, and will displace the PAM monster. After all,
} isn't this what progress is all about?

     Yes.  And, I have no problem with that.

} Authentication aside, I think the more difficult issue is the NSS. getp*
} functions are bound to the C library. It's far easier to authenticate a

     Yes, this certainly is a problem,  However, it is complemtary to
the PAM issue.  It will be helpful to have it, but PAM doesn't depend
on it.  Anyways, with NetBSD moving to a completely dynamic system, I
expect this will be fixed shortly.  I.e. as soon as somebody can come
up with a suitable API for NSS modules and do the work to dynamically
load them.

} user with a non-PAM method (e.g., SSH which uses a specialized version of
} 'login') than to either use NSS, or write your own NSS replacement
} without doing things such as linking your database library into the C
} library. Once a user is authenticated, he's stuck because his UID/GID,
} supplementary groups, etc are unknown to the OS without NSS module.

     Perhaps.  You might be using PAM in conjunction with a RADIUS
daemon which authenticates users for an access server.  In that case,
UID etc. isn't needed; just some form of logging to indicate what user
was logged in when and on what line.  The last project I did involving
PAM used a template user and RADIUS.  The local machine didn't know
anything about the user that was logging in, but it did know about the
template user.

}-- End of excerpt from Dan Melomedman