[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Source code for Pam'd applications
- From: Alan DeKok <aland cryptocard com>
- To: pam-list redhat com
- Subject: Re: Source code for Pam'd applications
- Date: Thu, 04 Feb 1999 10:30:23 -0500
Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz> wrote:
> I have PAMified linux-ftpd. See http://www.dcit.cz/~kan/pam/.
A snippet of which is below.
> + case PAM_PROMPT_ECHO_OFF:
> + /* cheat with the password */
> + text = strdup(pampasswd ? pampasswd : "");
> + if (!text) goto die;
> + reply[count].resp_retcode = PAM_SUCCESS;
> + reply[count].resp = text;
> + break;
> + case PAM_TEXT_INFO:
> + /* ignored */
> + break;
> + case PAM_PROMPT_ECHO_ON:
> + case PAM_ERROR_MSG:
> + default:
> + /* some error */
> + goto die;
I'm really uncomfortable with the idea of applications implementing
security policy through partial PAM support. Maybe the code structure
of linux-ftpd doesn't handle this well, but there seems to be no
reason why PAM_TEXT_INFO can't result in a '331' message.
The problem with many applications (as I see it) is that PAM support
is grafted on to replace the original static password support. PAM
does a LOT more than that, and so do most application-layer
protocols. So instead of making a PAM-compliant application, it
becomes PAM-aware, because it ONLY supports static passwords, and
refuses to do what PAM & the system administrator tell it to do.
e.g. Ignore PAM_TEXT_INFO messages, and die on PAM_PROMPT_ECHO_ON
It takes a lot more work to integrate PAM into an application, but
I believe the benefits are worth the work.
Alan DeKok.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[]