On Tue, Aug 29, 2000 at 11:49:07PM -0400, Nicolas Williams wrote: > (2) was never part of the proposal. Right -- sorry for messing that up. Still, what I meant to say, is, that if an application needs integrity protection and/or encryption, PAM has no API to provide it. So, a secondary solution like GSSAPI or TLS is required. > Adapting an app to use GSS-API generally requires protocol and code > changes. > Adapting an app to use PAM+binary prompts requires server-side code > changes only. While that seems correct on the outside, everything that PAM can negotiate has to be specified in a protocol. So, the correct way to put it is "PAM+binary prompt requires no *additional* protocol changes". No brainer, if you ask me. > Originally I suggested adding a pam_gss_authenticated() API. Then Andrew > asked if I could go further. I looked into the binary prompts, thought > about it and fell in love with it. Thats something else entirely. I tried to argue that PAM does *too much* already and that all this integration stuff (wether done through an extra function or through binary prompts is not the issue) only arises because of that. The conclusion would be that the complete problem could be neatly sidestepped by *limiting* PAM to the things it does well. Which, in my personal and very humble opinion is: 1) authenticating *interactive* logins (e.g., login or xdm) and 2) authorizing arbitrary sessions. -- Ingo Luetkebohle / 21st Century Digital Boy its easy to stop using Perl: I do it after every project