--- Bill Studenmund <wrstuden@netbsd.org> wrote:
> On Tue, 24 Sep 2002, Dan Melomedman wrote:
> 
> > Here are some of my thoughts about PAM as an
> authentication system:
> >
> > Too complex than needs to be. Why loadable
> libraries as part
> > of the design? Why not a client/server model? Or
> even a simpler exec
> > chain model such as checkpassword or CVM? In a
> client/server design, the
> > modules (executables) could all conform to the
> same simple interface for
> > passing credentials to the server. This would
> allow the modules to be
> > either statically or dynamically linked; a
> sysadmin would have a
> > choice. Debugging would be trivial, the modules
> themselves would be much
> > smaller in size, and the API could be very simple.
> 
> I can't say why loadable modules are part of the
> design of PAM, but I do
> know why a number of NetBSD developers want a
> loadable-module system.
> Because the other systems (well, not sure about CVM)
> you mention above are
> too limiting. The problem with a fork/exec model is
> that, as I understand
> it, all it can do is say yes or no. There are a
> number of authentication
> schemes that neem more than that. Like AFS, where
> you need in-kernel
> "tokens." These are kerberos credentials that AFS
> uses. They must be
> loaded IN THE PROCESS. No form of helper
> authentication method can
> substitute for that.

So an authentication server cannot supply the
credentials for the client to use?  If *file
descriptors* can be passed via pipes (or am I
mistaken?), I am sure something can be done, despite
the "impossibility" of using a client/server model. A
server can return MORE than yes/no. As far as I can
see, tokens or credential would be stored as data and
data can be sent via messages/requests.

> The problem with the client/server approach is
> similar; you can only
> perform methods expressable in the client/server
> protocol. To try and do
> something else, you have to change the client code.
> Which means, without
> dynamic modules, relinking everything. The whole
> point is to try and be
> able to add new authentication methods w/o
> relinking, so that really
> doesn't cut it.

Only if the client/server protocol was poorly designed
and non-extensible. I suppose OSes based on a
microkernel should find it impossible to support AFS
because in these EVERYTHING is abstarcted to message
passing?

> > Why loadable modules again? Because the designers
> tried to avoid
> > fork/exec overhead? Or a message over socket
> overhead? Is the overhead
> > really that high to warrant such a design? Measure
> it, you'll note some
> > other syscalls take far more CPU than fork/exec.
> 
> See above. At least for us, it's not a question of
> optimizing something,
> but of fundamental design. If you're doing
> authentication and you aren't
> in the process you're authenticating, you limit what
> you can do.

Not really. Anything that can be copied or passed via
reference can be put in a communications channel (like
file descriptors). If it were not so, then the list of
complaints against microkernel OSes would include
fundamental theoretical limitations (and not just
speed/performance).

> > Also I find PAM configuration files confusing, and
> the whole system very
> > hard to debug. I doubt the files are easily
> parseable, and editable by
> > software too. Simplicity and ease of use
> definitely weren't design goals
> > there, IMO.
> 
> Is that an issue with design or implementation?
> NetBSD hasn't come up with
> a loadable-security-module implementation yet, so
> saying we shouldn't do
> one because others have done it poorly is premature.
> Saying what you think
> others have done wrong is good, though, and can help
> us not make said
> mistakes.
> 
> > Authenticatiion is the easy part, because all you
> need is request
> > username/password, give to the authentication
> server, and get OK/FAIL.
> 
> Nope. While OK/FAIL will go a long way, there are a
> number of auth systems
> it won't do. And that's the whole point above. For
> those systems, AFS in
> particular, you also have to load credentials (make
> syscalls()) IN THE
> AUTHENTICATED PROCESS.

A syscall may itself be implemented via message
passing, although it is not done so in most systems
including NetBSD. Perhaps the client/server model is
incompatible with the way NetBSD works, but that
doesn't mean that it is inherantly less capable. Is it
REALLY a technical hurdle OR is it just "we don't do
it that way"?

>
[...]
>

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca