Description of Problem:
If I call authnone_create() in one thread, and then try to use
it via AUTH_MARSHAL in another thread, the AUTH_MARSHAL call
fails because authnone_private is grabbed from that thread's
local state (where it's still null).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a multi threaded program that does RPCs with a shared client handle
RPC fails with CANTENCODEARGS
Looks like each thread needs to do an authnone_create() or something similiar
to initialize this. Shouldn't it just default?
Why do you think it is a bug?
RPC is not shared between threads, each one has its own.
1. The behavior was different in the glibc delivered with Red Hat 6.2.
2. The RPC client handle is a global handle in a library that is shared among
a single applications threads. The first call into the library will cause the
handle to be created. Only this thread can use the handle. If the other
threads want to use the handle, they have to do an some form of authentication
instead of picking up the default 'authnone' from the 'clnt_create'. According
to ONCRPC when a client handle is created with one of the clnt..._create()
functions, the credential fields are NULL, signifying no credentials or
verification to be performed at the server. However, it appears that with
glibc-2.2.4-13 this is not with the client but private to a thread which is
good if you want to have different threads have different credentials.
However, I still think that all threads should first get "a default" and then
be able to change this default as needed.
We have been bitten by this bug as well. The required workaround places a
serious bookkeeping burden on multi-threaded clients.
This excerpt from Sun's online documentation gives a good indication of the
In a multithread client program, a thread can be created to issue each RPC
request. When multiple threads share the same client handle, only one thread at
a time will be able to make an RPC request. All other threads will wait until
the outstanding request is complete. On the other hand, when multiple threads
make RPC requests using different client handles, the requests are carried
out concurrently. Figure 4-1 illustrates a possible timing of a multithreaded
client implementation consisting of two client threads using different client
Thanks - email@example.com
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at
Changing bug status to ASSIGNED.
This is how RPC in multi-threaded apps is designed to work now. Before the
change (before RHL7.2) RPC better never was used in multi-threaded apps. It
couldn't work reliable. Now the RPC state is thread local which brings with it
its own set of limitations but it's better than nothing.
Yet on 04-22, you said,
On Thu, 2002-04-11 at 15:12, Zack Weinberg wrote:
> sunrpc/auth_none.c contains static private data, which is initialized
> once per calling thread by authnone_create(). authnone_marshal
> accesses this data by the per-thread data pointer.
I've applied the patch now. It indeed seems to be consistent with
Solaris does. Thanks,
I was also bitten by this bug, but applied the patch from RedHat 9,
and the problem is fixed.