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

Re: Internalization, prompts and passwords



Stephen Langasek wrote:
> Ah, internationalization and PAM, two of my favorite issues :^D

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.

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.

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

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

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

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

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

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?

Cheers

Andrew



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