summaryrefslogtreecommitdiff
path: root/security
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2012-09-15 01:24:02 +0400
committerTrond Myklebust <Trond.Myklebust@netapp.com>2012-10-02 02:33:33 +0400
commitba9b584c1dc37851d9c6ca6d0d2ccba55d9aad04 (patch)
treed74fa5a04f928d5c508594f285381b41bfe4ac3c /security
parent1b63a75180c6c65c71655c250a4e6b578ba7d1c0 (diff)
downloadlinux-ba9b584c1dc37851d9c6ca6d0d2ccba55d9aad04.tar.xz
SUNRPC: Introduce rpc_clone_client_set_auth()
An ULP is supposed to be able to replace a GSS rpc_auth object with another GSS rpc_auth object using rpcauth_create(). However, rpcauth_create() in 3.5 reliably fails with -EEXIST in this case. This is because when gss_create() attempts to create the upcall pipes, sometimes they are already there. For example if a pipe FS mount event occurs, or a previous GSS flavor was in use for this rpc_clnt. It turns out that's not the only problem here. While working on a fix for the above problem, we noticed that replacing an rpc_clnt's rpc_auth is not safe, since dereferencing the cl_auth field is not protected in any way. So we're deprecating the ability of rpcauth_create() to switch an rpc_clnt's security flavor during normal operation. Instead, let's add a fresh API that clones an rpc_clnt and gives the clone a new flavor before it's used. This makes immediate use of the new __rpc_clone_client() helper. This can be used in a similar fashion to rpcauth_create() when a client is hunting for the correct security flavor. Instead of replacing an rpc_clnt's security flavor in a loop, the ULP replaces the whole rpc_clnt. To fix the -EEXIST problem, any ULP logic that relies on replacing an rpc_clnt's rpc_auth with rpcauth_create() must be changed to use this API instead. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions