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

Re: Using pam to check a known password.

> I can think of one way to do this without having to write bad conversation
> functions.  However, I'll leave it for others to decide whether this is more
> or less bad than the alternative. :)

Which alternative?  There're at least two: bad assumptions in the
conversation function and pam_userpass.

> #include <security/pam_appl.h>
> #include <security/pam_modules.h>
> ...
> int retval;
> char *user, *password, *service;
> const struct pam_conv conv_struct = { ... };
> pam_handle_t *pamh = NULL;
> ...
> pam_start(service, user, &conv_struct, &pamh);
> pam_set_item(pamh, PAM_AUTHTOK, password);
> retval = pam_authenticate(pamh, PAM_SILENT);

Been there, tried that.  Won't work.

> Of course, this method has its problems.  First, I'm not sure how seriously
> libpam takes the edict that PAM_AUTHTOK is 'for modules only!'; it's possible
> that it will ignore the application, or reset the pam_item when
> pam_authenticate is called.

Linux-PAM will reset PAM_AUTHTOK.  You can avoid that by playing with
pamh->former.choice, but that's undocumented and non-portable.

> Second, while this will eliminate the vast
> majority of reasons why modules would need to call the conversation function,
> the whole reason there's a problem is because modules sometimes need
> information *other than* a username or password.  The above method does
> nothing to help those modules.

There's no problem with providing some information via tokens you set
manually and the rest via a conversation function, if that was possible.

Solar Designer

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