Subject: Re: PAM
To: None <email@example.com>
From: Ken Hornstein <firstname.lastname@example.org>
Date: 09/24/2002 15:54:08
>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.
Let me apply this to the AFS example to make it clearer.
In the AFS world, I need to add to the user's process two groups to
the front of the group list (They're really an index into a kernel table
that holds the Kerberos credentials). To do this I call a special AFS
system call that does the right magic for me. After I do that, I need
to call another AFS system call to place the Kerberos ticket into the
kernel so that the AFS client can use it. This is non-negotiable; it's
the way AFS works (I don't want to get into the long explanation WHY
it's this way right now; just trust me on this one).
How do I do this via a message-passing interface? I don't really see a
way. I mean, yes, the child could pass the necessary bits through a
message to the parent process, but the parent would still have to know
that these were AFS (or Kerberos, to use another system) specific
things and do the "right" things with them - and at that point you
start losing any advantages of this system. The advantage of PAM here
is that since this all happens in the same address space, you can do
the sorts of funky things in the parent process you need to do to make
your authentication system work properly.