In article <20050507152257.47C2137042@arioch.imrryr.org>,
Roland Dowdeswell  <elric@imrryr.org> wrote:
>When we imported PAM we changed the semantics to fail closed rather
>than to fail open.  We did this by denying an authentication if
>neither a required nor a sufficient returns true.
>
>The language describing the PAM keywords is rather confusing, so
>I will construct a table of how [our] PAM works.  The four columns
>represent:
>
>	continue:F	will continue on failure
>	S		will continue on success
>	can succeed	sets the ``can succeed'' flag
>	force deny	sets the ``will be denied'' flag
>
>requests which make it through the stack will succeed if both
>the ``can succeed'' flag is set and the ``force deny'' flag is
>not set.
>
>So, here is how I read our current set of keywords:
>
>keyword		continue:F	S	can succeed	force deny
>-------		----------	-	-----------	----------
>required	yes		yes	yes		yes
>requisite	no		yes	yes		yes
>sufficient	yes		yes	yes		no
>optional	yes		yes	no		no
>binding		yes		no	yes		yes
>
>Now, if we consider a module such as pam_nologin.so, none of
>those definitions make sense.  We really want something like:
>
>X		yes		yes	no		yes
>
>which is unrepresented in the table.
>
>Or in English: the success of pam_nologin.so should not by
>itself allow you to log in to the system.  Consider /etc/pam.d/login:
>
>auth            sufficient      pam_self.so             no_warn
>auth            required        pam_nologin.so          no_warn
>auth            sufficient      pam_krb5.so             no_warn try_first_pass
>auth            required        pam_unix.so             no_warn try_first_pass
>
>If a system administrator naively comments out pam_unix.so, then
>anyone can log into the system at any time---so we still have a
>system which can [sort of] fail open.
>
>This, IMO, needs to be fixed.  So, we can take either one of two
>paths.  The first would be to come up with a PAM configuration
>syntax which has some semblence of sanity.  This would diverge from
>the standards which would be unfortunate.  The other would be to
>change the semantics of a keyword or add a keyword.
>
>I think that it might be a better idea to just extend the current
>syntax to include an additional keyword ``neccessary'' which would
>specifically not imply any kind of sufficiency.  The table above
>would become:
>
>keyword		continue:F	S	can succeed	force deny
>-------		----------	-	-----------	----------
>required	yes		yes	yes		yes
>requisite	no		yes	yes		yes
>necessary	yes		yes	no		yes
>sufficient	yes		yes	yes		no
>optional	yes		yes	no		no
>binding		yes		no	yes		yes
>
>And /etc/pam.d/login would become:
>
>auth            sufficient      pam_self.so             no_warn
>auth            necessary       pam_nologin.so          no_warn
>auth            sufficient      pam_krb5.so             no_warn try_first_pass
>auth            required        pam_unix.so             no_warn try_first_pass
>
>or
>
>auth            sufficient      pam_self.so             no_warn
>auth            necessary       pam_nologin.so          no_warn
>auth            sufficient      pam_krb5.so             no_warn try_first_pass
>auth            sufficient      pam_unix.so             no_warn try_first_pass
>
>At this point, if one comments out the last line the request will
>fail if pam_krb5.so fails which is more intuitive.
>
>``Necessary'' might be a bad choice of words, but at this point I
>think that all of the words except sufficient and optional are poor
>choices...
>
>Comments?

I really like this. Can we bring the openpam people in this discussion?
It would be nice if this change was made in the base openpam code.

christos