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:	Tue, 9 Sep 2008 13:07:40 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Cedric Le Goater <clg@...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 Sep 9, 2008, at Sep 9, 2008, 11:29 AM, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@...ssion.com):
>> "Serge E. Hallyn" <serue@...ibm.com> writes:
>>
>>> Thanks, Cedric.  Eric is probably right about the long-term fix, but
>>> yeah it might take a while to properly wade through the sunrpc and  
>>> nfs
>>> layers to store the nodename at nfs mount time, and in the  
>>> meantime this
>>> fixes a real oops.
>>
>> A very esoteric oops that hasn't shown up for two years.
>
> But an easily reproducible one.
>
> It's not as though we'll stop looking for the right fix just bc we  
> have
> this "bad" fix in for a short while.
>
>> Please let's look at this and see what it would take to fix this
>> properly.
>
> Of course.  Cedric is looking at the best way to fix it...

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.

>> 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

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?

> I don't want to do this, but we *could* put a conditional in utsname()
> to have it return init_utsname if current->nsproxy is null...

I don't like the idea of an oops in here.  Instead, (for now) it  
should warn and fail to create the client, IMO.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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/