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]

Message-ID: <m1ej3rixbx.fsf@frodo.ebiederm.org>
Date:	Wed, 10 Sep 2008 13:02:10 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	chucklever@...il.com
Cc:	"Cedric Le Goater" <clg@...ibm.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

"Chuck Lever" <chuck.lever@...cle.com> writes:

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

Interesting.

As a general rule I would say we should capture the uts instance
in locked_up().  And use the same instance in locked_down().

I'm not at all familiar with how locked interacts with nfs mounts
in a practical sense.  Is there one locked instance (or at least context)
per nfs mount?

The way I would expect things to work is that when we mount an nfs filesystem
from an nfs server.  We would create a locked context for that server, that
additional nfs mounts to the same nfs server could share.

The way I would expect nfs to interact with the namespaces is for the nfs
mount to capture the uts and network namespaces, and use them for all
transactions relating to the mount.  In particular when creating
or a locked context the nfs mount would use the uts namespace and the
network namespace as discriminators to see if an existing locked context
is the same.

I don't think nfs has a 1-1 thread to context model which is where things
get really hazy for me.

The conservative play is to always force use of the initial namespace
and to deny creation of mounts that would use different namespaces.  In part
because the initial version of the namespace always exists.  Which means
as relates to Cedrics initial patch we would still need to know which
mounts should cause us to use a different uts namespace so we can deny
them.

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