--vH3HHxf962mwD/qo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 07, 2005 at 11:22:57AM -0400, Roland Dowdeswell wrote:
> The language describing the PAM keywords is rather confusing, so
> I will construct a table of how [our] PAM works.  The four columns
> represent:
>=20
> 	continue:F	will continue on failure
> 	S		will continue on success
> 	can succeed	sets the ``can succeed'' flag

=2E.. *on success*

> 	force deny	sets the ``will be denied'' flag

=2E.. *on failure*

> 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.
>=20
> So, here is how I read our current set of keywords:
>=20
> 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

At last this makes sense to me!  Please add this to the documentation. =20

Well, almost: 'optional' seems like a NOP to me in this table, useless
unless it's there so the module can have some side-effects? What might
they be?

> Now, if we consider a module such as pam_nologin.so, none of
> those definitions make sense.  We really want something like:
>=20
> X		yes		yes	no		yes
>=20
> which is unrepresented in the table.

Yes! Yes!

(are there other unrepresented combinations that might be useful?)

> 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.

We have a security system where even smart, experienced security
experts are left scratching their heads and drawing truth tables and
wondering what will really happen, even if they think they've figured
it out.  That includes possibly failing open, but even if it doesn't
it is still not right.

> 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.=20

It would. There are a lot of people using this syntax, sane or
otherwise.  I'd like to avoid that divergence too.

If the standards are broken beyond repair, we should diverge from them
without fear, but in doing so we should make it clear (perhaps by
using a different syntax entirely) that people used to other systems
should not expect the same behaviour here, otherwise we have a
different form of the same understanding problem.

One such change which would make it less confusing is to have two
columns for keywords, one to describe the four possible continuation
behaviours, another to describe the four possible flag-setting
behaviours.  This would also inherently eliminate the 'no keyword for
the behaviour I want' cases, like above.

For example, the meanings of 'required/necessary/sufficient/optional'
are much clearer if they're only encoding the 'can succeed/force deny'
columns, and some new keywords encode the continuation behaviour.

> The other would be to
> change the semantics of a keyword or add a keyword.
>=20
> 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.

Yep, I like this, within the current context/syntax.

> ``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...

I agree with this entirely.  As I suggest above, there is too much
information encoded into a single english word. =20

If we are to diverge, either we split the encoding, or we make it more
explicit (less dependent on english interpretation).

Since I find your table quite helpful, I would be tempted to suggest
that we change the syntax to match the table and allow all
possibilities. Either by having four new columns in place of the
current 'keyword', two columns as above, or by defining a system of
names that encodes the table more directly than the english keywords,
and adding them as aliases alongside the current ones as a compatible
extension to the current syntax.

as a simple straw-man suggestion, a four-character ls-alike:

 c: continue      -: don't
 s: can succced   f: force deny

keyword            c:F  c:S  can succeed  force deny
-------            ---  ---  -----------  ----------
required   =3D ccsf  yes  yes  yes          yes
requisite  =3D -csf  no   yes  yes          yes
sufficient =3D ccs-  yes  yes  yes          no
optional   =3D cc--  yes  yes  no           no
binding    =3D c-sf  yes  no   yes          yes

I'm not sure this is great either, but at least I don't have to spend
several minutes thinking about the difference between 'required' and
'requisite', or 'requisite' and 'binding' each time - and worse, if
there are more keywords added, or I'm not a native English speaker.

--
Dan.
--vH3HHxf962mwD/qo
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFCfUBPEAVxvV4N66cRAr3zAKCGyajIfmJBMFE2eq/wxASj6DtxBwCfWAQX
sco2xHgXL8ojz55/Ff4myFA=
=IA5r
-----END PGP SIGNATURE-----

--vH3HHxf962mwD/qo--