On Wed, Aug 30, 2000 at 04:54:05PM +0200, Ingo Luetkebohle wrote: > 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. Hmmm, no, why? If there's a PAM module for an auth system not supported by, say, FTP, and yet it's listed in FTP's PAM config then that module will simply return PAM_IGNORE when it's pam_sm_authenticate() method is called. Why? Because when that module asks ftpd if that auth system is being used ftpd will answer "I don't know what you're talking about, so NO". > So, the correct way to > put it is "PAM+binary prompt requires no *additional* protocol > changes". No brainer, if you ask me. Ok. > > 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. I beg to differ. The problem I have with GSS-API and Kerberos and so on is that you still have to map principal names to usernames, and that's not always trivial. Moreover, you still have to support something like .k5login and what if you want to replace .k5login? Well, then you have to modify ftpd/telnetd/login.krb5 and so on, whereas with PAM you'd just have to replace a single module. But PAM can't do that, yet. So I argue that PAM, as it stands, is only good for authorizing interactive sessions where the user is authenticated using basic auth. It seems a few simple changes will allow PAM to get involved in the authentication phase of sessions authenticated using Kerberos, NTLM and so on. The changes?: - export pam_set_data() and pam_get_data() to the PAM apps; - make libpam call pam data cleanup functions when pam_end is called, delaying the calling of cleanup functions when pam data is replaced; - establish conventions for modules to prompt apps, not for usernames and passwords, but for GSS-API/Kerberos contexts, tokens, creds, etc...; - in fact, binary prompts aren't all that necessary here, as long as pam_set_data() and pam_get_data() are available to the app for exchanging non-string data with PAM modules; - then make some utility functions to hide the conventions mentioned above (e.g., pam_gss_authenticated()). Only the first two items are actual changes to PAM. And they're small changes, methinks. Is there any reason NOT to do this? I'm not convinced that this approach is bad. In fact, I'm getting more and more convinced it's good. But it wouldn't pay off till several apps where modified to use this approach. > -- > Ingo Luetkebohle / 21st Century Digital Boy > Nico --
