Dirk van Deun <dvand...@wilma.vub.ac.be> writes:
> Hi,
>
> I really like the fact that you can use user_unknown=ignore to
> introduce pam_oath gradually, and it works fine if you use one users
> file to store all the secrets; but when you use a file per user
> (like with usersfile=/oath/${USER}), users that do not have a secret
> yet do need an empty file for PAM_USER_UNKNOWN to be returned;
> without, you get a file-not-found kind of error instead.
>
> It is debatable whether this is a bug or just unexpected behaviour,
> but to me it would make more sense if in such a configuration, a
> missing file would also lead to PAM_USER_UNKNOWN.
Yes this makes somewhat sense. The patch to get your behaviour would
probably be something like this:
diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
index 25eb83e..f5ae490 100644
--- a/pam_oath/pam_oath.c
+++ b/pam_oath/pam_oath.c
@@ -303,7 +303,7 @@ pam_sm_authenticate (pam_handle_t *pamh,
DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
oath_strerror (rc), ctime (&last_otp)));
- if (rc == OATH_UNKNOWN_USER)
+ if (rc == OATH_NO_SUCH_FILE || rc == OATH_UNKNOWN_USER)
{
retval = PAM_USER_UNKNOWN;
goto done;
Although since (IIRC) 'user_unknown=ignore' is handled by the PAM layer
and not the pam_oath module, I worry that if we start to return
PAM_USER_UNKNOWN on file-not-found errors, we will cause unwanted
behaviour in other situations.
One ugly way to resolve this is to introduce a new keyword that cause
this particular behaviour to happen, for example
'missing_usersfile_leads_to_user_unknown' causes OATH_NO_SUCH_FILE
errors to be translated into PAM_USER_UNKNOWN. What do you think?
Would you like to make an attempt to make a patch?
/Simon
signature.asc
Description: PGP signature
