Why Samba didn't use pam to hook into cracklib

[Andrew Bartlett]

On Mon, 2005-04-25 at 18:30 +0100, Dave Love wrote:
> [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 at 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.

I did not wish to modify (and then redistribute, particularly given the
Artistic Licence) the cracklib library.

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

This would require the configuration of PAM for correct operation, which
in Samba's case is just too much to ask.  We can control our own
configuration, but PAM configuration is both very hard to debug, and an
extra burdon on the administrator.

Even given that, Samba would still need to tell the difference between
'poor password' and 'sucess' (being failure, caused by pam_deny) from
the PAM stack, or place itself as the actual module changing passwords,
with similar complexity in that direction.

> > 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'?

Samba is in the position of using the PAM password chat, I don't think
we have the ability to influence the PAM process in this way.

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

Correct.

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

Checking against previous passwords should be handled by the server, and
Samba now does this.  I wasn't aware that pam_cracklib handled any
aspects of password history.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050426/f2b45204/attachment.bin