Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp480221imu; Thu, 3 Jan 2019 01:20:46 -0800 (PST) X-Google-Smtp-Source: ALg8bN7k+QDCFbYWIfTvbv2RdlQam6mnYgHoumMP6/NGbfBK+/MdFfa5tEu5HfRcsiephSpxrf9p X-Received: by 2002:a17:902:20e9:: with SMTP id v38mr3718583plg.250.1546507246269; Thu, 03 Jan 2019 01:20:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546507246; cv=none; d=google.com; s=arc-20160816; b=YgUPAWwk1yybMOFtiHhLIL3z25pc80mboA6LittjESHG1hHoWBrTVLCcbsMEycy7cD eQGTFyq0b21GzESf/7tK/xzxsLLTcW2vBXlpLBb0NIsyIH207nJE8NMgk9OCCvUPQMoU 9WBtcQ0/C3UYI1GQacVlKGlN4P3TXfy9WFZhPNTfczFsDFLbtZ5xax/ooMqAZm39eA9h uL5kYOvYkZK7tRZGIcuc+brY2krL8zANy4lGFfC3pwRJtb334zrAyZAyJJylLQwnwAlE 4xsfn3cOh4XqVS4NwXVe2kHX2QC+e3+1ROXLZip0c8cr6qKfFfwVPpvReT+JUWWZk/Mp xSLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from; bh=wToYjxgwOpx6YqPBfUrzzVB+oDEmaQC+nPtlh7SLfz4=; b=OK/vhlteczI33wbeiLfAo8NdnEHvb+hxYIHjG6264crxtIvDQAYCBYK/t683q5naWD dYmpryBkU6OvDzt5cbOAudDYrdoL+ARbnqqJ5aS+bNApLk1nwW/Be7MjSn4VXFGSJGi4 iXjjwD/AHPr/EAMgQp4BoS1dg2HsZnx1LmgkCq8HwX6gYCg8XLg3kRfTO9tW/4wjfF6b skWjaNWsrUAmvT57rSc/MefH+jxV9Ktg7ODv+z+3AK0lVv9MJu55K6dXWRYm3IhNC83m ul8jXQbjXmgo8QvUeIM3dwO3G48s2Nb7C1b3npGWrC84yxlZ9ItBtBsxns0HJlG1uyAP h0Eg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q66si51711719pfb.231.2019.01.03.01.20.31; Thu, 03 Jan 2019 01:20:46 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729590AbfACExz (ORCPT + 99 others); Wed, 2 Jan 2019 23:53:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:33398 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726058AbfACExz (ORCPT ); Wed, 2 Jan 2019 23:53:55 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 849F1ABCB; Thu, 3 Jan 2019 04:53:53 +0000 (UTC) From: NeilBrown To: Linus Torvalds , "Schumaker\, Anna" Date: Thu, 03 Jan 2019 15:53:46 +1100 Cc: "linux-kernel\@vger.kernel.org" , "linux-nfs\@vger.kernel.org" Subject: Re: [GIT PULL] Please pull NFS client updates for 4.21 In-Reply-To: References: <02d3ecd37f9390e7b8a7be8ec0e1cafb7fdbed26.camel@netapp.com> Message-ID: <87bm4yl4th.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain On Wed, Jan 02 2019, Linus Torvalds wrote: > On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna > 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. > > Looks ok to me, although I wonder what the semantics of cred_fscmp() > are across namespaces? > > IOW, it seems potentially a bit suspicious to do cred_fscmp() if the > two creds have different namnespaces? Hmm? > > Is there some reason that can't happen, or some reason it doesn't matter? > > Linus 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? 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? 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. Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlwtlVoACgkQOeye3VZi gbm/ixAAktdfJtR1DCg61/XBAcZ8oyAfYkamWYl3El3pkVwqIqtDCmMVG+N7pH2/ 57ZM9cAKjRW97kyC/2c6+8vNxj02X35r6BcYw4wCZr8j4DUzv1y2fiowVTsg+0sd BMwMCPqBjwOP4++6+ZSUYy7odE5HCwNrLkhmfbbM/Uoe/ScKmkhGZna6l11JI3Uy CuvnSL9jNRc5VFsrr5gYld/MqBxUWvlLqk4VhMpvIUUrDnF2dcx/nOTwKzEMWndw MjU1C4Qi/NQfKI/HpiyAqcMvZZh40dkaHXtdt+z05/DBRkXHjRASqDh2cezA9yUt 3dcRWiRCGwT1O4IJxYbFOp09P8I15q/l7R4JuJ8QH6WllAqGcJxI0ZU7uHmNVIV+ /mA8j2D/W3J5E/A1S0zPTY4y3uh5U9Pn+DyqRy4rc/ahpKLv465WXrkH4GK/y4JD YI8Za/tzE2vUQvpHouAflqzZO6A2EcYynMTimZBGIxszAqaWu+AKgCIxcw35hopl NnIe7YCLjSUTGYL0eBLIoSaeImCx/088YRzH64LMIyfWfuxHbGJsxogeN+pqqC4E EyZrJMUSWsqOzObt2Uet1/IksKZ3uDcXsSxe3J+goRxoHSyLKzbXKaH5nRlkd2q6 LGqtK001/M+A+2Ujs60jcXLgRHAXlRUr6po595fkk/HpmkRPPeU= =GsrE -----END PGP SIGNATURE----- --=-=-=--