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, 09 Sep 2008 17:40:54 +0200
From:	Cedric Le Goater <clg@...ibm.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Chuck Lever <chuck.lever@...cle.com>,
	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

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

yes. well, my eyes are making progress in the NFS code. it will take some 
time :)

>> 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?
> 
> 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 nearly did that one but it will hide future misusage of utsname(). So 
I think it's better to keep it that way, and let the machine oops when
we need to fix our code. 

C.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ