In message <>,
Martin Forssen writes:
> On Sun, 7 Feb 1999, Jean Chouanard wrote:
> > At 08:15 AM 2/7/99 -0800, someone using Andrew Morgan's login wrote:
> > > a. add some generic message exchange types to the client and the
> > >server (echo'd prompt, invisible prompt, binary prompt (raw data
> > >exchange) etc..)
> > Yes and this has to be properly defined to be generic enough so that it
> > will stable in the future. Piece of cake! :-)
>
> I must admit I am no expert on PAM, but from what I can see there are
> two distinctive modes. One where it expects to talk to an user and one
> where it expects to talk to some program (via the PAM_BINARY... messages).
>
> Implementing the first one is simple and only needs one simple
> modification of my draft (addition of a message packet from server to
> client witha bit to indicate error). Since the replies are expected to be
> retreived from teh user the client does not need to know anything special.
>
> The second one is tougher. The one thing I haven't found anything about in
> the documents I have read is that how does the client know which module to
> use? I might sit at a client with a smartcard reader, a retinal scanner
> and a fingerprint reader. How do the client know which to use?
The client doesn't use any PAM modules. Presumably the prompt string
includes enough information so the user knows what auth device to use.
This gets kind of broken with PAM_BINARY, but I don't think it's
a good idea to implement that at this time anyway.
What the original message referred to (which you must have accidentally
elided :) ) was PAM support on the *server* side. In this case, it's
still transparent to the server, everything is done within the PAM
libraries.
I will post my proposal tomorrow (after I have time to dig it up and
clean it up).
~frank
