Bug 1260 - Multiple brokeness in support of cracklib in the configure.
Summary: Multiple brokeness in support of cracklib in the configure.
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Build environment (show other bugs)
Version: 3.0.2a
Hardware: All FreeBSD
: P3 major
Target Milestone: none
Assignee: Andrew Bartlett
QA Contact:
Depends on:
Reported: 2004-04-12 15:01 UTC by Timur Bakeyev
Modified: 2005-11-14 09:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Timur Bakeyev 2004-04-12 15:01:22 UTC
There are several problems in the way how cracklib is detected in the configure,
that make it mostly unusable on non-RH(?) platforms.


in configure.in:


That line effectively kills any ability do disable cracklib or change it's
location. Possibly, result of forgotten debug statement. Should be removed!

# test for where we get FaciestCheck from
AC_MSG_CHECKING(where to use cracklib from (default=$dictpath))


At least in my version of cracklib:

dictpath - the  full  path  name of the CrackLib dictionary, without the suffix.

So, it looks like:


So, the message, that describes this switch for configure should reflect
that(jist take a given in a manpage description - it's much more clear).


I wonder, where cracklib, after which the whole check was written was taken
from. The only one, which I found around was cracklib 2.7, taken from
http://www.crypticide.org/users/alecm/security/. It is the one, available in
FreeBSD and Slackware at least. And the one on which google points to.

The problem is that this version doesn't have ANY crack.h header file. So, both
test/crack.c and smbd/chgpasswd.c try to use non-existing header, that breaks
both detection and compilation.

So, at least AC_CHECK_HEADER(crypt.h) and the proper surrounding in this code
files is necessary.


The last problem is the handling the results of detection. It doesn't matter,
what they are, but if the system HAS libcrack, it'll be linked against, even if
it is recognised to be broken - in both cases LIBS will contain -lcrack and
binaries will be linked against it, even if it is broken....

    LIBS = -lcrack -lcrypt  -liconv
    KRB5_LIBS =  -L/usr/lib -lgssapi -lkrb5 -lasn1 -lcrypto -lroken -lcrypt
    LDAP_LIBS = -lldap -llber
    AUTH_LIBS = -lcrack -lcrypt  -lpam -lpam

Sorry for putting everything in one file, but for such a simple check it's
better to rewrite it according all the given problems, rather than doing it
incrementaly with several bug reports.

If anyone interested I can write modified check.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-04-19 18:38:16 UTC
--with-cracklib support has been removed for 3.0.3rc1.  It 
will be readded later via a script interface.
Comment 2 Andrew Bartlett 2004-04-22 05:17:52 UTC
I'm hoping to add cracklib back via the script interface - probably as a
compiled binary, so any assistance in getting the configure magic right would be

Comment 3 Timur Bakeyev 2004-04-22 15:41:32 UTC
Yes, sure, just give me bare bones :) Or say, in what form you would expect the
script :)
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-02-07 07:39:53 UTC
originally reported against 3.0.3pre1.  Moving back to version to 3.0.2a
to remove preX and rcX versions.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-02-07 07:42:12 UTC
originally reported against 3.0.3pre2.  Moving back to version to 3.0.2a
to remove preX and rcX versions.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:25:36 UTC
database cleanup