Re: [owl-users] tcb and friends with shadow-utils 4.0.12

From: Vincent Danen (vdanen@private)
Date: Mon Jul 03 2006 - 23:18:00 PDT


* Solar Designer <solar@private> [2006-07-04 08:28:17 +0400]:

> I wrote:
> > > OK, this suggests that the problem is in fact with crypt_blowfish or the
> > > way it is integrated or compiled.  And I think that I know what it is -
> > > most likely, you need to increase BF_FRAME in x86.S:
> > > 
> > > 	http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/x86.S.diff?r1=1.4;r2=1.5
> > > 
> > > Sorry it did not occur to me to mention this to you before.
> 
> On Mon, Jul 03, 2006 at 10:02:11PM -0600, Vincent Danen wrote:
> > I don't think that was the problem.
> 
> I am almost sure that it was.

Ok, well, you know more than I so I'll take your word for it.

> > What I ended up doing was taking the patch that SUSE was using and
> > re-adding a few bits (they never touched crypt/Versions so some
> > symbols weren't being exported or available that pam_tcb wanted ...
> 
> Oh, that's not good.  It means that people can't compile pam_tcb on SUSE
> Linux even though they (almost) have crypt_blowfish in glibc.  Maybe you
> can contact SUSE folks (Thorsten Kukuk?) about that?

As soon as this is squared away so I can tell them exactly what needs to
be done, absolutely.

> > After about a half-dozen glibc compiles and puttering around, bcrypt is
> > working now (strange... I've had it for over 2 years and never even
> > tried it so it's been broken all this time).
> 
> It might not have been broken all this time.  If the problem is what I
> think it is, it should have appeared with your move to gcc 4+ only.

Hmmmm... well, I'll be damned:

[vdanen@build 2.0-CURRENT_32]$ ./bcrypt-test 
+ perl -e 'print crypt("foo", "\$2a\$05\$abcdefghijklmnopqrstuu"), "\n"'
$2a$05$abcdefghijklmnopqrstuuz29TNT43FrbrkSgusq0SUVtGQkhH2mm
[vdanen@build 2.0-CURRENT_32]$ rpm -q gcc
gcc-3.4.4-5113avx

I think you're right.  My build host is running 1.2-RELEASE, which has,
as you can see, gcc 3.4.4.  And the test worked.

> > http://svn.annvix.org/cgi-bin/viewcvs.cgi/releases/2.0-CURRENT/glibc/SOURCES/glibc-2.3-avx-suse-crypt_blowfish.patch?root=packages&rev=5738&view=markup
> 
> This confirms my guess.  This patch has:
> 
> -#define BF_ASM				1
> +#define BF_ASM				0
> 
> This disables the assembly implementation, thus avoiding the problem
> with BF_FRAME being too small.

I noticed that part, but didn't think too much of it because I didn't
know what that was.  I'm assuming then that, despite putting x86 into
the libcrypt-routines part of the Makefile, it wasn't actually being
used, correct?

> I suggest that you drop this SUSE-derived patch and go back to our
> recommended way of integrating crypt_blowfish (as described in its
> README or as implemented in Owl), but increase BF_FRAME.

Ok, I see BF_FRAME is set to 0x200, but I have no idea what would be
sufficient to increase it too.  Care to give me something I can replace
that with and recompile?  It would probably be faster than me
recompiling glibc a few times to find something suitable.

> > Right now I'm having an issue with userdel complaining that it can't
> > lock the shadow password file, so it's not deleting anyone.
> 
> Now that's likely a bug in your forward-port of the shadow suite patch.

I thought so too, but embarrassingly enough, my spec was passing "CFLAG"
rather than "CFLAGS" so -DSHADOWTCB was never being passed.  Right now,
as things stand, it looks like it's working perfectly, although I need
to do some more testing to call it finished (and, of course, go back to
how it was before, but with the increased BF_FRAME).

> > If nothing else, it's been a bloody challenge... =)
> 
> Perhaps we should do something to make this easier.

Well, you can tell me what value to use for BF_FRAME for starters... =)

> If newer gcc does indeed require a larger BF_FRAME (in fact, I recall
> this being mentioned to me before), we'll increase the default.
> 
> Thank you for not giving up on this!

Well, sometimes I can get really determined...  I recall spending about
3 weeks trying to get SSP properly integrated into both glibc and gcc
about a year ago and finally gave up, but it took me three weeks to get
there.  I think one long weekend invested turned out not too bad.  =)

-- 
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)
:: Annvix - Secure Linux Server: http://annvix.org/ ::





This archive was generated by hypermail 2.1.3 : Mon Jul 03 2006 - 23:19:17 PDT