Deon George wrote: > When I start the openafs-client, the host can successfully read the directory > unauthenticated (and the contents below it). > > After some time, openafs refuses (unauthenticated) access - and a restart of > the openafs-client re-enables it.
Other people are seeing strange behavior with pr_GetHostCPS() calls
in the file server. A group of us have a theory on what is going on
and we are attempting to validate it.
ubik_Call() does provide a prototype because it is used as a
pseudo-vararg function.
afs_int32
ubik_Call(int (*aproc) (), struct ubik_client *aclient,
afs_int32 aflags, long p1, long p2, long p3, long p4,
long p5, long p6, long p7, long p8, long p9,
long p10, long p11, long p12, long p13, long p14,
long p15, long p16)
But what happens when the parameters that are being passed into
ubik_Call for later use by 'aproc' do not have the same size as
a 'long'? In that case the alignment of parameters on the stack
is going to be wrong and the values passed to 'aproc' will be
incorrect.
We believe that this is happening on some systems and that as
a result some ubik_Call() calls are resulting in damage to the
stack and random behaviors.
The gatekeepers are working on a replacement for ubik_Call()
that won't be susceptible to this problem.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
