Re: [OATH-Toolkit-help] pam_oath and pam_unix' try_first_pass

[Simon Josefsson]

Christian Hesse <address@hidden> writes:

> Christian Hesse <address@hidden> on Wed, 2012/05/09 11:55:
>> Hello everybody,
>> 
>> This is from man pam_unix:
>> > try_first_pass
>> >            Before prompting the user for their password, the module first
>> > tries the previous stacked module's password in case that satisfies this
>> > module as well.
>> 
>> I think pam_oath has a similar option.
>> So I tested with these in my pam configuration:
>> 
>> auth sufficient pam_unix.so
>> -auth required pam_oath.so usersfile=/etc/users.oath digits=6 try_first_pass
>> 
>> and
>> 
>> -auth sufficient pam_oath.so usersfile=/etc/users.oath digits=6
>> auth required pam_unix.so try_first_pass
>> 
>> My understanding is that I get one prompt that accepts unix and oath
>> password. But obviously this does not work, authentication fails for the
>> line containing try_first_pass.
>> Anything I misunderstood? How is this expected to work?
>
> I did some debugging... Looks like pam_get_item() at line 161 writes a memory
> address to password that is not guaranteed to persist. The memory is
> overwritten or cleared in pam_set_item() at line 275, thus the following
> strncpy() does not copy anything useful.
>
> The attached patch fixes it for me, though I am not sure this is a 'clean'
> way...

Thanks for debugging!  Could you analyze a bit further why the patch
solves the problem -- maybe the password returned via

      retval = pam_get_item (pamh, PAM_AUTHTOK, (const void **) &password);

stop working later down in that function?  Could you pin-point where?
Maybe it goes away after this call?

      retval = pam_set_item (pamh, PAM_AUTHTOK, onlypasswd);

That could make some sense.  The PAM library might re-allocate or use a
static buffer for the password, and this call overwrites the earlier
value.

Is there an easy way to reproduce the problem you discovered?

/Simon