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

Internalization, prompts and passwords

There is going to be some complaints in this message, so first of all I'd
like to thank all of you who have been making Linux-PAM possible. IMO,
PAM is a great thing and I Just don't want to sound too much like a
whiner :)

Anyway, I'm writing a PAM-aware getty/login replacement (I call it
nicegetty) for Linux console  (and perhaps serial-lines and incoming
telnet connections), which has many kdm/gdm like features in text mode.

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

The second problem is, that I really (really!) want to have my
users to be able to fill out password and user input fields first and
only after that call pam_authenticate(), since I am actually inside an
event loop, where the user might want to do something completely different
than to login (one of the main features of nicegetty would be to allow
users to easily do things from the console with no authentication at all, 
since many Linux users are using their machine at home and therefore the
need to authenticate at console is only a nuisance).
Also I am playing with the idea, that I can use PAM from withing same
process with different application names for different things :
"nicegetty" for login service and "shutdown" for being able to shutdown
the machine for console. Currently I can't do that, if I do the
pamification of nicegetty using the conversation function
for user prompting.

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.

The third problem (bear with me, this will be the last) with PAM API is
that it does not support applications which have no way of communicating
with the user and really can do only basic user/password authentication.
Many current network server protocols fall in to this category, including
at least FTP, POP and SMB (and HTTP unless you want to be really 
kludgy). However, one of the strengths of PAM is the ability to change
actual implementation of the user/password authentication without touching
the application itself; so programmers who want to use PAM are
sometimes forced to write conversation functions like this (this excerpt
comes from Samba. I had nothing to with it.):

/* PAM conversation function
 * Here we assume (for now, at least) that echo on means login name, and
 * echo off means password.

The solution to all these problems would be to extend the API with
an alternative conversation function which would take arguments
of type "struct pam_alt_message" which would be defined like

struct pam_alt_message {
	 int msg_type;
         int msg_style;
         const char *msg;

and there would be few predefined message types like
so that pamified application would know when PAM wants a password and
when PAM wants something which was invented long after the application
was written.

If this not possible, then I would at least like to know the best way of
attempting to guess what PAM actually wants. Should I do it like 
Samba does it, or should I try something 'strcmp(message->msg,"Password:
")==0'? Or am I just hopelessly ignorant of something I should have found
in the PAM-documentation?

Thanks for your time!

- Jani (for whom writing long articles in english is rather painful)

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