Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Trond Myklebust <trondmy@hammerspace.com>
To:     "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com>,
        "neilb@suse.com" <neilb@suse.com>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [GIT PULL] Please pull NFS client updates for 4.21
Thread-Topic: [GIT PULL] Please pull NFS client updates for 4.21
Thread-Index: AQHUouxyssLuTL6Yhkqph5BlSbCk6aWctiQAgABEoQCAABU9gA==
Date:   Thu, 3 Jan 2019 06:09:58 +0000
Message-ID: <55e9d0eb47662f2d6c308eba8b9a84fbba978ac8.camel@hammerspace.com>
References: <02d3ecd37f9390e7b8a7be8ec0e1cafb7fdbed26.camel@netapp.com>
         <CAHk-=whZkaZn1UQLad6v9vmfx8+BB3m8cvT0wcKdtg=k=FDbGw@mail.gmail.com>
         <87bm4yl4th.fsf@notabene.neil.brown.name>
In-Reply-To: <87bm4yl4th.fsf@notabene.neil.brown.name>
Accept-Language: en-US, en-GB
Content-Language: en-US
received-spf: None (protection.outlook.com: hammerspace.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; micalg="pgp-sha256";
        protocol="application/pgp-signature"; boundary="=-h8TepRE+u8G8DM8XQDRF"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b859f849-c657-459b-fcc5-08d671421736
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2019 06:09:58.9513
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0d4fed5c-3a70-46fe-9430-ece41741f59e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2416
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--=-h8TepRE+u8G8DM8XQDRF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2019-01-03 at 15:53 +1100, NeilBrown wrote:
> On Wed, Jan 02 2019, Linus Torvalds wrote:
>=20
> > On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna
> > <Anna.Schumaker@netapp.com> wrote:
> > > We also were unable to track down a maintainer for Neil Brown's
> > > changes to
> > > the generic cred code that are prerequisites to his RPC cred
> > > cleanup patches.
> > > We've been asking around for several months without any response,
> > > so
> > > hopefully it's okay to include those patches in this pull
> > > request.
> >=20
> > Looks ok to me, although I wonder what the semantics of
> > cred_fscmp()
> > are across namespaces?
> >=20
> > IOW, it seems potentially a bit suspicious to do cred_fscmp() if
> > the
> > two creds have different namnespaces? Hmm?
> >=20
> > Is there some reason that can't happen, or some reason it doesn't
> > matter?
> >=20
> >                   Linus
>=20
> Interesting question.
> For the current use in NFS, it is consistent with existing practice
> to
> ignore the name space.
> NFS file accesses (when using the normal uid-based access checks)
> always
> use the manifest uid of the process - the one returned by getuid()
> (or
> more accurately, getfsuid()).
> Maybe this is wrong?  Maybe we should always use from_kuid() or
> whatever
> to get the uid/gid to send over the wire?
>=20
> Anna/Trond: do you have thoughts on this?  If a process in a user
> namespace accesses a file over NFS, should the UID presented to the
> server be the one in that name-space, or the one you get by mapping
> to
> the global name-space?
> Or should we map to the namespace that was active when the filesystem
> was mounted?
>=20
> I don't think cred_fscmp() should do any of this mapping, but maybe
> it
> should treat creds from different namespaces as different - as a
> precaution.
>=20
> Thanks,
> NeilBrown

The values being compared are in cred_fscmp() are all of type kuid_t or
kgid_t so that means they have already been mapped from the user
namespace into the kernel uid/gid space.
When we put those kuid/kgid values onto the wire, we currently always
use the init namespace rather than the user namespace of the mount
process.

When using strong authentication (i.e. krb5) then none of this matters,
since the server performs its own mapping of the presented RPCSEC_GSS
session into a credential. That mapping is independent of the user
namespace on the client, it just depends on which krb5 principal the
process used to identify itself.

The problem case is limited to when we're using the weak AUTH_UNIX
authentication, since the server is then implicitly trusting the client
to protect against identity spoofing. This is particularly true if the
NFS server is being accessed through NAT, in which case it has very
limited possibilities for discriminating between containers on the same
client using the export table because they will all originate from the
same source IP address. I think that for these cases, using the init
namespace is the right thing to do for the same reason we use it with
local filesystems: if we try to use a different namespace then
unprivileged userspace processes might be able to manipulate the
mapping to spoof the identities of privileged users or groups, or
otherwise gain access to files to which they normally should not have
access.

Does that argument make sense?

--=20
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com


--=-h8TepRE+u8G8DM8XQDRF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESQctxSBg8JpV8KqEZwvnipYKAPIFAlwtpysACgkQZwvnipYK
APK87w//TpoS1RM7UB8nC/rUTgiRygcFJVzuK1LiWMqlbSnjoNK3d+1JxSm1veX+
HFfntccs3hM8hBMPbGA/s7ICw2e4ugJjAW4M/WBJlNuxfVB08QuAVACT3O8c/DIi
or160Kpp0aHP/VA9hRFLWVQH/BXq36KGTcBT/mlElvZjutOuGO1OlQYonWNbKn0H
iDK4t8TqTcyiG7kQMJclz4IMHQuNq1BXoi/Zx+BFrr/9E/PNoR0lrTBoKKHhQ5kH
Ekt70zxQlHKZKoirrUmPJv4aO2KAp/3EH40h4F+Av5HkQozTPna9R3FRIvc9Arpd
rMXoK5cuxHphoQ2HaUiOgex32FAI6uIYRz5+G8g50IhJRX4jeTvJ4d1O5pp1xkBc
70jrdcqd5eDhJZzKl0GxYlM0pmp+jn+1TYU7ydTy6NMzlsJsfZ9eiKp6XVBSBBFE
TFWlHlAux8no1gHqyiOFzfKzveh61ZQa3ymLXh6dof08Tua1zZDVjUn01mTHjtcw
+U2pZHP61GFLLVCkPBDHNDkZl/To1Lsm48UAHCt4cD2Yn64kXJMUqZV0STamyAKS
ChnZfUMxu0GQNrkUeVYElNDLIyKjguvHC/ZI5DnZ0cAKGQx0I4jvsTt4kK3UADC0
IE4vwojOvsn7WQxw1bka2uAdN6C77mK8sTOaue20gQrlFnWulqw=
=4g5R
-----END PGP SIGNATURE-----

--=-h8TepRE+u8G8DM8XQDRF--