Re: Why Samba didn't use pam to hook into cracklib

[Dave Love <d.love@dl.ac.uk>]

[This is late, and probably moot, but I'm puzzled and I may need to
understand it eventually.  Sorry if I'm bing dense or haven't looked
closely enough at the implementation.]

Andrew Bartlett <abartlet@samba.org> writes:

> This misbehaviour (we could not make our admins debug that kind of
> behaviour) led to the patches removal, and later, Simo Sorce added
> another patch - this time, we called an external helper, as a fork()ed
> child, and he created examples/auth/crackcheck.c from the remains of my
> previous patch.  This is called when 'check password script' is set.

Why didn't you just replace the nearly-trivial top-level routine in
cracklib (the one that calls exit)?  It seems to me that the PAM
module should do that anyway.

> Hmm, but I haven't explained 'why not PAM'.  We looked at PAM as an
> interface to existing, working cracklib code shipped on many of our
> target OS platforms, but it is not a very good fit at all.  In the PAM
> case, Samba wants to be both the client application, and the target
> library to which the password may be set.  This is complex, both because
> the target library is a configuration issue outside the control of
> Samba, and because we would then have to ship the 'actually set the
> password' part as a PAM module, not as part of the main Samba code.

Why would you have to do so?  pam_cracklib doesn't actually set the
password; it's typically stacked over something that does, but not
necessarily.  I assumed the PAM config for this would just use
pam_cracklib (and pam_deny?), but not pam_krb5 &c.  The suggestion was
only to use it as a convenient check in the server, with the potential
to replace and stack existing modules.

> We also hit against the issue of PAM as 'no previous password'.  If we
> are setting a password without the previous plaintext, we have to be
> root (otherwise the previous password is prompted for),

I can't remember how this stuff is called, but why doesn't it work to
call into PAM with the programmatic equivalent of `use_authtok'?

> I would suggest cracklib be
> integrated into the password check API of heimdal as a child process, so
> that the two ways that a password may be set in my current directory
> setup are covered with some kind of check.

Does `two ways' mean via Heimdal and via Samba?  Presumably multiple
way of changing passwords should be covered by _identical_ checks, not
just some check.

> On my unix workstations,
> I'll probably also enforce local pam_cracklib, as this can get previous
> passwords, as well as return decent error strings.

It may be reasonable to run it locally, as well as on the server, if
that gets you better diagnostics, but you then have the problem of
keeping them in sync with respect to the parameters used (if you don't
just use the defaults and all your clients install consistently).
Also, the old password data are stored locally, so if you're using
multiple boxes it's likely that the check will be against the wrong
store.