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

proposal: pam_setcred behavior change


I've been struggling with trying to make some sense of the pam_setcred
return stack. Its chaos. The basic problem is that there is no way to
manage it effectively.

For whatever reason, the original PAM RFC indicated that it shares a
configuration with that of the auth stack (used for pam_authenticate),
but in the light of complicated return codes and the resulting control
flow, it's fairly hard to be sure that the setcred stack executes
identically to the auth stack. The problem I'm facing is that of making
multiple invocations of a single module in a single auth stack. The
question at hand being which of the pam_sm_authenticate() calls is the
one that corresponds to a given pam_sm_setcred() call, and as a result
which return value is appropriate..?

Our previously agreed upon work around convention is that we encourage
authentication module writers to ensure that the pam_sm_setcred function
returns the same thing that the pam_sm_authenticate function returns...
This gets harder when an admin decides to stack a given module a number
of times. Basically, the module writer has to remember the retval for
pam_sm_athenticate for each set of arguments and any environmental
context too... As I say, this is hard (it may not actually be possible
in general) for the programmer to do this in a way that the admin won't
at some point trip up.

I'd like to revisit the idea that we adopt a different strategy. One of
the following:

  1. invent another stack flavor (split the auth stack into auth and
cred stacks).

  2. get libpam to 'remember' how an auth module returned and use this
info to chart a course through the modules' pam_sm_setcred() functions.

Does anyone have another suggestion?



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