linux-kernel - Re: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Sep 2008 11:12:04 -0400
From:	"Chuck Lever" <chuck.lever@...cle.com>
To:	"Cedric Le Goater" <clg@...ibm.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Trond Myklebust" <trond.myklebust@....uio.no>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Linux Containers" <containers@...ts.osdl.org>,
	linux-nfs@...r.kernel.org
Subject: Re: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared

On Wed, Sep 10, 2008 at 5:23 AM, Cedric Le Goater <clg@...ibm.com> wrote:
> Eric W. Biederman wrote:
>> Chuck Lever <chuck.lever@...cle.com> writes:
>>
>>> If the upper layers are responsible for providing the utsname, you will need to
>>> fix up lockd and the NFS server's callback client too, at  least.
>>
>> Actually looking at the code.  It looks like a proper fix may be  even simpler.
>> Why do we have both clnt->cl_server and clnt->cl_nodename?    Or is cl_server
>> the other side of the connection?
>>
>>>>> What are we trying to achieve by reading utsname?
>>>> It looks like it gets copied into the sunrpc messages so I assume it is
>>>> a part of the sunrpc spec?
>>> It appears to be used only for RPC's AUTH_SYS credentials.  The nodename is used
>>> to identify the caller's host.  See RFC 1831,  Appendix A:
>>>
>>>   http://rfclibrary.hosting.com/rfc/rfc1831/rfc1831-16.asp
>>
>> Thanks that helps a lot.
>>
>>> I'm not terribly familiar with uts namespaces, though.  Can someone explain why
>>> we need to distinguish between these for AUTH_SYS if the  caller is on a remote
>>> system?
>>
>> Semantically processes in different uts namespaces are on different machines.
>>
>>> I don't like the idea of an oops in here.  Instead, (for now) it should warn and
>>> fail to create the client, IMO.
>>
>> Which is interesting when the problem happens during NFS unmount.  Although
>> frankly it could fail anyway.
>>
>> It seems strange that we are creating a client during unmount anyway.
>
> the task exiting brings down the lockd thread and unregisters the lockd service
> with the portmapper. This is done with a rpc call which creates a client and a
> request.

That makes sense.

This is likely coming from lockd_down(), and is almost certainly not
coming from the same uts namespace as the lockd_up() that did the
pmap_set, which was done by the first NFS mount done in the first uts
namespace on the system.  It's just something that the kernel has to
do for maintenance.

There is only one lockd() instance that is shared among all the uts
namespaces, right?  In this case, what is the correct utsname to use?

-- 
Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/