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

Re: Internalization, prompts and passwords



On Wed, 29 Sep 1999, Jani Jaakkola wrote:

> One of my design decisions was, that there should be no user visible
> strings embedded inside the C code, so that internalization of the user
> interface could be done just by editing the configuration file. However,
> if I use PAM (by the book) I cannot do this, since PAM:s prompts all seem
> to be written inside the PAM-modules in C, so only way to change is to
> recompile PAM, or use some crude hackery (like deciding that "Password: "-
> prompt  really is "Salasana: "-prompt, if you happen to live in Finland).
> So I think that PAM really needs to support setlocale() or at least
> some way of specifying alternative prompt-strings in PAM configuration
> files (and this should addressed by the documentation too!)

Ah, internationalization and PAM, two of my favorite issues :^D

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.  

I'm willing to help work on internationalization of modules in the Linux-PAM
distro, if it would make a difference.

Calling setlocale() should probably remain the sole responsibility of the
application, 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.

> 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.  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?

Nevertheless, you're right that this is a concern with PAM, and no one's
come up with a definitive solution yet.

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.

-Steve Langasek
postmodern programmer



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