[OpenAFS] Fwd: Bug#415952: openafs-client: klog fails with an "bus access error" for password longer then 8 symbols.

[Russ Allbery]

Marcus Watts <mdw@spam.ifs.umich.edu> writes:

> It's a shame there's not a bit more information here.
> If compiled with "-g", it ought to be possible to see line numbers
> and procedure arguments, which would be helpful.  Absent that,
> it would have been interesting to see the current instruction
> and register contents, or better yet, instructions from the last
> subroutine entered up to around the point of failure...
> As it is- the above traceback appears to be ignoring static routines
> where it's probably actually dying.

Yeah, I'm not sure why the debugging information was so lame.  Although..
hm, maybe this is because we strip stuff in our install rules.

> Anyways, to take a stab in the dark: pwlen.gt.8 characters goes to
> StringToKey (instead of Andrew_StringToKey), (in src/kauth/client.c).
> This calls des_key_sched with 2 parms, char temp_key[8] and
> des_key_schedule schedule.  Somewhere inside the depths of
> des_key_schedule, it is indeed assumed that the key schedule can be
> accessed as integers.  Presumably this is what is failing.

Yup, that would do it.

> So, key_schedule in stock 1.4.4 is defined this way:
> typedef struct des_ks_struct { des_cblock _; } des_key_schedule[16];
> That is, an array of 16 blocks of 8 characters.  The C compiler will
> indeed only give that character alignment, so a problem is quite possible.
> A relatively simple fix is to instead do this:
> typedef struct des_ks_struct { int _[8/sizeof(int)]; } des_key_schedule[16];
> which will give it exactly the same size but require int alignment, which
> is what is required.  This should compile and work without errors; the
> fieldname itself is never used.

This loses if we ever get an int larger than 8 bytes, right?  (Not that
I'm expecting that soon... maybe DES will be gone by then.)

I'll send the bug reporter a patch and see if that change solves their
problem.

> I don't see any reason why this would suddenly start to fail on sparc --
> was the compiler changed recently?  Could BUFSIZ be defined by stdio.h
> to have an odd value?  Regardless, it has probably been a latent bug for
> a long time.

It's probably a change in compilers somewhere along the line.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>