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

Re: Internalization, prompts and passwords




On Wed, 29 Sep 1999, Stephen Langasek wrote:

> Obviously, the cleanest way to accomplish what you're looking for would be
> to internationalize/localize the individual PAM modules, but this would
> require more effort on the part of module writers (or at least coordination
> between module writers and those interested in internationalizing them).  I
> would personally recommend the use of gettext for this.  

It would probably be a big effort; But I think it's worth it.

> Calling setlocale() should probably remain the sole responsibility of the
> application, yes?

Yes.
 
> One thing to keep in mind is that typically, users have the luxury of
> setting their locale in their shell environment when they log in.  For the
> types of services we're talking about here, applications would need to know
> the locale before login, sometimes even before the user has been identified.
> This of course means that we'd be establishing a global locale for the
> system.

I am mostly talking about authenticating application spesific locale; in
my application there would be button with texts "English", "Finnish"
and "Klingon" where the user could select one. So the locale needs not to
be written down by the system administrator.

> > 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.
> 
> As a general rule, the application can prompt for the username before
> calling pam_authenticate, and then store this in the PAM_USER item using
> pam_set_item().  This way, most well-behaved modules will never need to
> prompt for a username.
> 
> Beyond that, the PAM conversation function is intended to let the module get
> information from the *user*, /not/ from the application.  

Right. So I propose an alternative conversation function (or anything
else which solves the problem), which would be more appropriate for
conversations with applications, when conversation with user is not
possible.

> The whole point is
> to pass these messages to the user, and let the user reply as appropriate.
> In the examples you cite (FTP, POP, SMB), telling the application what
> information it should prompt for wouldn't help much anyway:  if the protocol
> only supports basic user/password authentication, then what good does it do
> the application to know that a module wants you to tell it your hometown?

My point is, that if password is asked from the application, the
application could answer if it knew the question (nowadays 
applications like Samba just seem to guess the question); If something
else is asked the application could answer "I don't know" or "I can't
answer this question".

So in short, I think that the conversation function has a design
problem: it was designed only for conversations with users, when it should
have been designed for conversation with users _and_ applications.

> Was this a hypothetical question, or is this a problem in your nicegetty
> application?  I would think getty would be flexible enough to get this
> information as needed.

I already got around it in nicegetty by using strcmp(question,"Password: ")==0,
which currently seems to work. However, I would like to have something
more general (and not so very ugly) like:  
if (question_type(question)==PROMPT_PASSWORD) answer(password);
which would work also after someone decides to change password prompt.

- Jani




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