crypt() is not required to be re-entrant, and is usually not re-entrant or thread-safe. But, some platforms provide a crypt_r() function, a re-entrant version of crypt.
Perl @15326 and onwards 5.8.* does the best it can and will attempt to
detect crypt_r and use if for crypt() operations, if it can't find it,
it'll default to regular crypt().
On my Linux box for example:
$> perl -V:version -V:d_crypt -V:d_crypt_r
version='5.8.0';
d_crypt='define';
d_crypt_r='define';
So, you might need to look at if your platrofm supports crypt_r and make
sure you are using a recent Perl that supports r_crypt. (Alternatively,
you might want to try and apply that particular patch to see if your
problem goes away before upgrading)
Hope this helps.
On Fri, 2002-10-04 at 03:08, Rick Bradley wrote:
> On Fri, 6 Sep 2002 08:23:33 +0200 Toma'? Procha'zka <[EMAIL PROTECTED]> wrote:
> > For comparsion of password user entered and password stored in database is
> > crypt function used.
> >
> > Here is the code:
> > my $real_pass = $d->[0][0]; # crypted password from database
> > my $salt = substr $real_pass,0,2; # salt
> > my $test_pass = crypt $sent_pw,$salt; # in $sent_pw is the password user entered
> > if ($real_pass eq $test_pass) {
> > $r->subprocess_env(REMOTE_USER => $user);
> > return OK;
> > } else {
> > $r->note_basic_auth_failure;
> > return AUTH_REQUIRED;
> > }
> >
> > Problem: Sometimes, although user entered correct password, is authentication
> > rejected. I tried logging values of $real_pass and $test_pass and they
> > differed. When I add line
> >
> > $r->log_reason("User $user tested (".$real_pass."/".$test_pass.")...","");
> >
> > just before 'if' statement behavior is most of time correct.
>
> I have also seen this problem. I am using RT [0] and have intermittent
> login problems where suddenly crypt() called from mod_perl will start
> generating the wrong return values [ i.e., $pass ne crypt($user, $pass) ].
> After some period of time the crypt() call will start generating the
> correct values again.
>
> Executing the exact same crypt() calls via a command-line
> perl -e 'print crypt([string], [string])' generates the expected
> (correct) results.
>
> If (in the code run by mod_perl) I replace:
>
> if ($pass eq crypt($user, $pass)) {
>
> with:
>
> $crypt = `perl -e 'print crypt(\"$user\", \"$pass\")'`;
> chomp($crypt);
> if ($pass eq $crypt) {
>
> Then everything works perfectly, though less quickly and blatantly
> insecurely. I have checked the failing $user, $pass and crypt() values
> thoroughly for wierdness and compared them to their successful
> counterparts. I am 100% convinced that crypt() is returning the wrong
> values. Note that the wrong values are consistent (i.e., they are not
> random, not changing, just not correct).
>
> My original RT problem report (including voluminous configuration
> information, but prior to the isolation of the crypt() issue) can be
> found at:
>
> http://lists.fsck.com/pipermail/rt-users/2002-September/010117.html
>
>
> Question: is crypt() thread-safe? I haven't had a chance to look at
> the source but I plan on doing so soon.
>
> A tiny bit more info:
>
> $ strace perl -e 'print crypt("foo", "bar")' 2>&1 | grep crypt
> execve("/usr/bin/perl", ["perl", "-e", "print crypt(\"foo\", \"bar\")"], [/* 22 vars
>*/]) = 0
> open("/lib/libcrypt.so.1", O_RDONLY) = 3
>
> $ ls -al /lib/libcrypt.so.1 /lib/libcrypt-2.2.5.so
> lrwxrwxrwx 1 root root 17 Sep 23 18:13 /lib/libcrypt.so.1 ->
>libcrypt-2.2.5.so
> -rw-r--r-- 1 root root 19136 Sep 17 21:50 /lib/libcrypt-2.2.5.so
>
>
> [0] http://www.bestpractical.com/rt/index.html
>
> Rick
> --
> http://www.rickbradley.com MUPRN: 812 (???F/???F)
> | me a line. It's the
> random email haiku | only commercial unix
> | I've ever liked. Wow.
>
signature.asc
Description: This is a digitally signed message part
