[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:

> One of the changes that we made to libpam a couple of years ago (which
> was hopefully the last backwardly incompatible change) was to add a pamh
> argument to the pam_strerror() function. This was primarily to resume
> compatibility with Sun who had changed it to pave the way for
> internationalized support. The pamh handle holds the user's environment
> which in can hold those LC_ variables, which in turn should be used to
> take care of issues like this.

This is interesting.  Although it would theoretically be nice to be able to
set a separate locale for each pamh, are there really any practical benefits
to this?  Are there forseeable cases where different locales will be
necessary within a single process/thread?

The one benefit I see to attaching locale information to the pam handler
is if a module needs to fork and pass the locale on to the child process.
For myself, I see little need for multiple concurrent locales within the
same thread, but if someone else thinks it would have practical applications
then it's certainly doable.
 
> I'm personally not clued in enough to do the work needed to make this
> transition, but I'd be extremely happy to see some patches for it for
> libpam at least.

Ok.  What do you see as being the best way to integrate this?  (If Linux-PAM
used autoconf or something similar, it would be easy to have the build
process autodetect gettext/setlocale support.  Is there any chance Linux-PAM
will migrate to autoconf in the future? :)

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

> As I say, I'm not clued in on the details, but my understanding is that
> certain daemons like telnet propagate LC_ environment variables - taking
> care of the question. For things like getty, it could well be
> appropriate to have some sort of global default. It might even be
> workable to make a module that could select the user's preferred LC_
> stuff early in the authentication sequence: English for you 'bob',
> Vietnamese for you 'tak'. Can you call setlocale() more than once in a
> given process? Having multiple locales one for each active pamh variable
> seems like the right thing be able to support, but I'm just not aware of
> whether this would work or not...

I don't think I've ever been in a telnet session where this propogation
occured.  Whether the fault was client-side or server-side, I don't know.

Yes, setlocale() can be called multiple times in a single process.  The
locale value is global to the thread, however.  If we're going to have
libpam or individual modules making their own calls to setlocale() to use a
different locale than the one used by the application as a whole, then it's
essential that the original locale be restored before control is returned to
the application.  (Easy enough to do: the previous locale is given as the
return value of setlocale().)

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

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

Oh. That too. I should probably know that by now, shouldn't I? :)

> 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... After all some admins might want to have guest logins only on
> certain machines and boot them straight to the desktop..? And for other
> situations getting to log in with a fingerprint is kind of fun (more
> about that later).

I suspect the difficulty will be in educating PAM application writers, so
their applications take full advantage of its (ever-increasing) flexibility.

-Steve Langasek
postmodern programmer



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