>I think you've been snowed.  PAM is no panacea.  Perhaps you should talk
>more to those who've actually tried to use it on a variety of
>non-compatible systems.  A lot of the problems you say you've been
>struggling with might disappear entirely if a different approach is
>taken.

I know a number of people that have tried it, actually ... I never said
it was a panacea, but it _is_ useful in many cases.

>For "bit-rotting research projects" I suspect you're referring to Robert
>Watson's experimental implementation of a new design in FreeBSD (and
>perhaps Linux too?):
>
>	http://www.watson.org/fbsd-hardening/tokens/fbsd-tokens-0.2/docs/proposal.txt

Greg, Greg, Greg ... did you actually _READ_ this proposal?

It's implements an API which is _almost_ identical to the one in AFS,
with a few extensions.  (The function calls have different names, of
course, but it's almost what you get from AFS).  That's not surprising,
since Robert Watson is an AFS/Coda guy.  Now, admittedly, Robert does
have a section of his proposal titled:

Transferring of Tokens (Not Yet Implemented)

... which is germane to this discussion.  But before _you_ said that there
were two solutions which had been "designed and implemented".  Doesn't look
like the token transfer has been implemented yet (and other than that, what
he has now is essentially the AFS interface).  I'm not saying Robert's
work isn't useful; standardizing on the API would be nice.  But you still
can't get a new PAG in Robert's model without doing it from the parent
process of the PAG, which means you need to be in the same address space.

>Regardless these ideas are only bit-rotting of course because folks such
>as yourself are happy to continue using the bad hacks of even more
>bit-rotted implementations.

Well, I haven't seen anything out of _YOU_ yet ... if I think the status
quo is fine, do you really imagine me investing my time in a re-write?

>Douglas Engert has also implemented some interesting ideas in this area:
>
>	http://www.ornl.gov/~jar/dfs-afs.html

But, unfortunately, Doug was only interested in getting DFS back
to the same level of functionality that AFS had.  From that document:

Separating the creation of the PAG from filling it in with information
is exactly the way AFS did it, the pagsh program for example creates
the PAG, and the klog program running as a child process adds the AFS
tickets. I don't know why DCE was not designed to do the same from the
beginning.

I actually know Doug fairly well, since he's the IETF Kerberos WG
chair, and we've shared code for years.  Doug's concern was that
basically, DFS didn't have an implementation of the AFS setpag(); they
had one function call that did both the setpag() and the set_token().
Doug found a way to work around that due to an undocumented feature of
DCE on Solaris, but the other DCE vendors never picked up that
feature.  But even in Doug's implementation, you still need to call
setpag() from the parent process.

So, you showed me two implementations that basically implement the same
API that AFS does.  Done by two people who also thought PAM is a good
idea.  Somehow, this wasn't exactly what I was envisioning when you
said two "designed and implemented APIs".

--Ken