[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Internalization, prompts and passwords

On Wed, 29 Sep 1999, Andrew Morgan wrote:

> > > So what I would like to have, is a way of knowing when the conversation
> > > function wants a password, when it wants a user name and when it wants
> > > something completely different, so that I can optimize the common case
> > > (username and password) but still be able to support retinal scanners and
> > > all kinds of spiffy things not invented yet.
> For the retinal scanner stuff, just make an effort to support the
> PAM_BINARY_PROMPT (via the libpamc library 0.69+) and you'll be ready.

Is there any documentation? How compatible this is (I want nicegetty
to work on RH5.2 machines).

> Actually, there is a place for the preselected username in the
> pam_start() argument list.

This is what I am currently using.
> One of these days I'm going to get to the bottom of that.
> It could well be the case that the legacy support we currently offer,
> however hokey, is all we'll be able to do. On a slightly related front
> my reading of the SASL rfc is that you generally support it from within
> PAM, and that seems to be something that more and more of these 'legacy'
> apps are adding support for.
> I'd like to think that all new 'PAM from the start' applications can
> leave prompt questions up to PAM and thus make them configuration
> options for the local admin as opposed to hard wired constraints in the
> binary... 

Standards sometimes implement hardwired constraints for protocols.
We cannot change SMB protocol to support PAM but we could change PAM to
support SMB: only thing that SMB-application needs to know is "what
i really was asked".

> BTW. I wasn't clear on the event loop thing in the original message. I
> have a suspicion that PAM_INCOMPLETE might be relevant to the original
> concern, could you elaborate?

It might be. Is there some documentation anywhere?

My problem is that when user presses enter to login, nicegetty calls
pam_authenticate(). Now if pam_authenticate() wants to prompt 
for something which which is not "Password: " (what is your favourite
color?), nicegetty needs to re-enter the event loop or drop
out from conversation function. Since I could not find any references to
situations where prompting is done outside of conversation function, I
decided to go with re-entrable event loop; So my event_loop() function
calls pam_authenticate() which calls event_loop() (by accident, my
event_loop() happened to be re-entrable). This works, but is kludgy and in
nicegettys case might cause some subtle problems (and probably does); I
would prefer having just one event_loop() call in my call stack.
(in other words: a way of implementing the conversation without having to
be inside the conversation function all the time).
IMHO, the conversation callback function is a design error in the PAM-api;
it would have been more flexible to have the PAM-API to return the
conversation structure with get_conversation_prompts(pamh) and
a response function answer_conversation_prompts(pamh). With those
functions you could easily implement the conversation mechanism which PAM
now has, but not the other way around. (Wasn't the PAM-API described in
some kind of Request For Comments? Hasn't anybody Commented this before?)

So In My Humble Opinion there are problems in the API; these could
be circumvented by inventing additional Linux-spesific interfaces (both
for applications and modules, if the module interface suffers from the
same problems). If this is not possible, then at least the best ways to
hack around these problems should be documented somewhere.

Yet again: how an application, which has no way of communicating
with the user and knows only about certain types of prompts
(Samba being a good example of this kind of application), should use PAM?
If there is no good way to use PAM with these kind of applications, 
then what is the least bad way of doing that? Should I use 
strcmp(prompt,"Password: ") or should I assume that ECHO_OFF really means
"give me the password"?

- Jani

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []