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

stack policy [was Re: 2nd Qs: proposed description of new pam_unix]

This issue is a good one to start a thread of its own.

There are three types of module stack that are problematic from the
perspective of PAM:

 1. the credential setting stack
 2. the pam_sm_chauthtok stack
 3. the session stack (open vs. close)

These module stacks can be called multiple (2 or more) times, and sanity
requires that the same (equivalent) sequence gets invoked on each

The credential sequence is logically dependent on how the
pam_sm_authenticate() got called. Our hack to make this go smoothly
(from an admin's perspective), is to add 'likeauth' arguments to modules
to encourage them to return the same value when called in both setcred
and authenticate ways. This is ugly, not well implemented and thus

The chauthtok stack needs to execute the same way both times it is
called (PRELIM_CHECK and UPDATE_AUTHTOK). Currently, its strongly
assumed that each module does the right thing - we have
stated/documented no policy for this.

The session stack is problematic for two reasons:

  a. we can't nest session modules since they close in a different order
to the way they open
  b. we rely on the session modules to return the same error codes to
drive the session stack the same way at both session open and close

Going forward, I believe we should solve this in libpam. We should cache
the path that these modules take the first time they are exectuted with
a successful result and that will dictate the way they get recalled
until pam_end() is invoked. [This is very vague, and needs a full
discussion before we commit to changing anything...]



Michael Tokarev wrote:
> That's ok, but issue is not here.  Issue is in stacking with other
> modules, and with some other (less-common) things.
> chauthtok() called twice, and this is not a question.  But the real
> question is -- will it be called with UPDATE_AUTHTOK if it returned
> error when called with PRELIM_CHECK set earlier?  This can happen
> if that module was declared "sufficient" while other module (that
> did authenticated user) as "required"/"sufficient".  In the other
> hand, other modules can change authtok on its own (due to even
> admin mistake), so things will be more "interesting".
> Also (less-common) thing is a locking.  It is bad idea to lock
> passwd database(s) during all passwd stack work (I said this
> earlier already).  And so, after verifying current passwd, there
> is a chance to have it already updated (by someone else?! :)
> when we will try to update it at the end.  So, this checking
> of old passwd compared to system's one _when updating it_ is
> useful here too.
> _______________________________________________
> Pam-list mailing list
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list

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