Phil, I had asked for what you ask for here, namely that apps be allowed to set PAM_AUTHTOK. Andrew Morgan refused on account of what the RFC said about the PAM_*TOK items, and then I suggested what Andrew Morgan actually implemented. Now, after some further thought, I come to realize that preserving PAM_*ATHTOK across pam_authenticate/acct_mgmt/ chauthtok/etc is a bad idea and actually can change the behaviour of PAM in certain circumstances. My apologies for that. As for the RFC, it is, IMHO, not complete, and, as I understand it, noone implements it fully and faithfully. I see no problem with allowing applications to set PAM_*ATHTOK prior to calling PAM functions. Nico On Tue, Feb 13, 2001 at 05:56:01PM -0000, Mayers, Philip J wrote: > I believe this change appeared in 0.74: > > ================= > > So, there is a bigger issue here - it should be possible for libpam > to work out whether the application or the modules are calling a > libpam function. This part I agree with and am going to implement. > > The other part, with respect to non-authentication functions getting > access to the AUTHTOK items, and I think I disagree with this. > > Having AUTHTOK items in memory for an arbitrary amount of time > is generally a bad thing - has no defined behavior in the face of > an arbitrarily stacked set of modules and one that libpam should > default to not supporting. > > I believe, as is currently supported by various modules, that > if a module requires that an authtoken is available subsequent to > the final return from pam_authenticate() then it should use a data > item to store the AUTHTOK it cares about - this is basically the > only way it can guaratee it knows what its doing. > > ================== > > So, back to my original query: > > What's wrong with code like this: > > pam_set_item(pamh,PAM_AUTHTOK, 'passw0rD'); > pam_authenticate(); > > It doesn't work in Pam 0.74 because of sanitisation. I'm only interested in > *one* application for this, and that's non-interactive programs which have a > username and password combination (think webservers and mail relays). > Clearly you'll sanitise the AUTHTOK on the way out. But on the way *in*?! I > know exactly what the reply is - "Binary prompts". But I don't want to use > that. I want something simple that works, which this does. try_first_pass > will still work. use_first_pass is an administrator choice. > > <sigh>:o) > > This is never going to happen, is it? > > Regards, > Phil > > +----------------------------------+ > | Phil Mayers, Network Support | > | Centre for Computing Services | > | Imperial College | > +----------------------------------+ > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list --
