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

Re: non-interactive authentications...

Savochkin Andrey Vladimirovich writes:
> Conversation function is introduced to display the prompt and read
> the answer in the current environment: via a box in GUI or just
> printing the prompt or making an appropriate request to the peer in
> the case of a remote session.

> The fact that a plenty of applications using PAM are broken by
> design only shows that PAM as it is doesn't satisfy developer's
> needs.

Is this because PAM does not satisfy developer's needs or because
someone with a knowledge of PAM has not taken the time to better
integrate PAM into an application?

My observation is that PAM, because it allows for quite general text
prompts (ignore binary prompts for now), should be able to mimic the
current authenticating behavior of any and all text based
applications.  This may require that someone extract the
authenticating code from the pre-PAM authenticating server application
and turn it into a module.

Let's take ftp (probably the archetypal offender in the "quick" PAM
support hack):

bash$ ftp alfred
Connected to alfred.nowhere.org.
220 alfred.nowhere.org FTP server (Version wu-2.4.2-academ[BETA-11](1) Mon Dec 16 17:10:41 EST 1996) ready.
Name (alfred:morgan):
331 Password required for morgan.

So without looking at the source for ftpd, but after scanning the
binary with the trusty 'strings' utility here are my thoughts:

Naively, it would appear that the 220 message is the "hello, please
tell me who you are message".  The message itself originates in the
server app: "%s FTP server (%s) ready.".

My guess is that the 220 part is a (protocol) indicator of the fact
that the message requires an echo'd response.  It is also the first
such prompt.  This could be something that the conversation function
can prepend to the module's greeting [see PAM_USER_PROMPT].  If the
220 is reserved for the first prompt, this contextual information can
be stored in the app_data pointer that is passed from the app to the
conversation function.

Similarly, the 331 message (to be found in ftpd as "Password required
for %s.") looks like a generic please give me your concealed-text

So, perhaps I am showing a wild lack of understanding of the ftp
protocol, but I would guess that a conversation function that looks
like this:

	switch (type) {
		send (331, text);
		read (reply);
		send (220, text);
	case 'PAM_ERROR_MSG':
		send (530, text);    /* login failed protocol # */
	case 'PAM_TEXT_INFO':
		send (257, text);    /* pwd protocol # */
		return PAM_CONV_ERR;

could be used as a first approximation of something that is sufficient
to support the existing default authentication scheme.  [Someone
wanting to implement this would obviously have to look more closely at
the ftp spec and possibly add some contextual decisions for what is
the appropriate protocol number based on the contents of the app_data

Having supplied this conversation function, people could immediately
extend the authentication of the application to suit their personal
preference.. stacking schemes etc., the real power of PAM.

Currently, by hard wiring the conversation to reuse the user/password
info gathered explicitly by the application, we have denied people the
opportunity to really use PAM for more than access control lists.

For other applications like POP, perhaps we need to beef up the
protocol to support more elaborate authentication exchanges, but it
should always be possible to do this in a way that we can
transparently support the old/default authentication scheme... If it
comes right down to it, we can write a module that will thus do
"normal" POP authentication.

I guess I've spent too long believing that PAM can be made to work.  I
used to have the time to just do this sort of coding... I'm still able
to offer advice, so if anyone wants to give it a try, I'd be happy to
look over their shoulder...



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