Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     Olga Kornievskaia <olga.kornievskaia@gmail.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Dai Ngo <dai.ngo@oracle.com>, Steve Dickson <steved@redhat.com>
Subject: Re: server-to-server copy by default
Thread-Topic: server-to-server copy by default
Thread-Index: AQHXxcrDI0R5Oq8J10KODCEElXm6xqvcFdwAgAATOoCAAAgsAIAADeKA
Date:   Wed, 20 Oct 2021 19:04:53 +0000
Message-ID: <EC5F0B99-7866-4AA6-BF2F-AB1A93C623DF@oracle.com>
References: <20211020155421.GC597@fieldses.org>
 <CAN-5tyHuq3wmU1EThrfqv7Mq+F5o0BXXdkAnGXch_sYakv=eqA@mail.gmail.com>
 <0492823C-5F90-494E-8770-D0EC14130846@oracle.com>
 <20211020181512.GE597@fieldses.org>
In-Reply-To: <20211020181512.GE597@fieldses.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?b18ErIuXPt1r4S/7ZHuUSmyJLK9jDm1KhZQLX7rfQXvFofLe70/LYmXEiq/N?=
 =?us-ascii?Q?7CCbsqMJz0RB0mCe7MOxZj0Zs19aFM9YkUpFnO8Mi3KZr7CKJKPWr1rng8Z6?=
 =?us-ascii?Q?Ex4VhmWmpa/sL0pE08x4dPMsTaa0HAeKrUvXubkvOiUit8oRn1i1yjB1XAqK?=
 =?us-ascii?Q?sNRKkxw2B2xGVEUwh/PZd4U+V6WW0+crXUGYja0N3GfwEp5TQ+xL/TiWhNvc?=
 =?us-ascii?Q?pMzjrAAfREXdWQY6RVI42iKsb7msLAloDqGzjW76JUSIZ7ouXhMfdTJF7sTd?=
 =?us-ascii?Q?T0Tl4yjM8Grbaif6XtHwjSw8dfJrABr0rF97rvkrcTQZOb9QYbGBPmj1bqZx?=
 =?us-ascii?Q?2vkUeTg/DsCj6b8bMt6TQJtWG2N7PYBpmXSMMIU5J2TS7S0oI724g2oCFoeS?=
 =?us-ascii?Q?QBAZN7KAf0/6Cz1J0eBgLTERcxyJAnTgcuSCUdj7/7r04gSv35ZRxxhVv0hH?=
 =?us-ascii?Q?TRw3NTtqHJejHfvdsUyQ7+fO8hZmWcKEdsKdhfB5V4hzDXDmh4cPWMe44ylo?=
 =?us-ascii?Q?Ng4bTP5hc+e4bgL2cGGVTO/ZH3dtBVH2IlACmQBjisEegRZfCijKEM2u73Pk?=
 =?us-ascii?Q?YipK0y2mWiDZQ/fIp7ASv7WmH+AWdH8z6MKCn3no/Ppnb5+A4ViKJExf+b6k?=
 =?us-ascii?Q?taurG5XHh7LxeN3D1wKbmgMmpy8hgRNrF/SYlIogJQ7wKH11QwDXeFZ1Guwf?=
 =?us-ascii?Q?ucB+R5JaxN0cE/hWwg58PVO739XFS7rcTPTiBAzD8cy33W7OOQJHP3VnsuPa?=
 =?us-ascii?Q?gdgK/EnxFzYkt97gXqdvs0K8ZIuYpo3khCpDuEsCubdmL7mIdfjdVQd2Qbom?=
 =?us-ascii?Q?kWkjFNQJqgggvIPLe+aB8sJDY7hS20M5UWNR7mzp9rQ48+jcv4t2+PWNkOBP?=
 =?us-ascii?Q?25wyzZBLmmHe1Jxip5uwacU6vZXOQCrcPRO7umG6gOL/+3mhrWHqy02c0tvO?=
 =?us-ascii?Q?nYBOwjyTyJ+D7+kPLqtehU310dEkDTU6KZ5ZEqrTM9aPVCTMRURzE/URsfgK?=
 =?us-ascii?Q?8gL7qmDa9jwZW7F450g9PkljqHiV540Lp8j4LPpUUjgsNvEiv8D2n82RTfaq?=
 =?us-ascii?Q?3AQytFkYtkRi7dfVq/bpY9E+KK/44SEu8c+4/6SlJIY/qErFO2Jg29Ijbn5a?=
 =?us-ascii?Q?nPuEIoYiK1wy2Ga+CV7RrbJDpzdJetiueyOPmu8SOXL1Vdyo4slKGq+rYBeG?=
 =?us-ascii?Q?FlcfbvoUlGBl5jlDwCQgOy+d8aZ3+Z5bD73h1hQVDSXSk4Uyh0XWuAF9iwnU?=
 =?us-ascii?Q?fr1BAMOHuoiZ2piT+ERx1vYAsPfJ9PrI2ZvWxQpihViDk5S1xH+ZpmqZOyV9?=
 =?us-ascii?Q?uBRIbWt2vEUdbl4AU6NWN//6?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AB44868D328BB04CB51C06ECDA0055AB@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4688.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c9d26f61-56d7-4aca-f59a-08d993fc7fdc
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2021 19:04:53.5108
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8N9QWqPUmpTA7yQIPrQw1rkKOR+kmLxRWclHcoVHT+CLL9BHUIfZEyaBdiKgwUPvnrK0t6r7V+KacZdVqrhkEg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3670
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10143 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 malwarescore=0
 phishscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001
 definitions=main-2110200108
X-Proofpoint-ORIG-GUID: GQLRwWy7EKbAWnYBlCfLPvJV8tU7rr1Q
X-Proofpoint-GUID: GQLRwWy7EKbAWnYBlCfLPvJV8tU7rr1Q
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Oct 20, 2021, at 2:15 PM, Bruce Fields <bfields@fieldses.org> wrote:
>=20
> On Wed, Oct 20, 2021 at 05:45:58PM +0000, Chuck Lever III wrote:
>>> On Oct 20, 2021, at 12:37 PM, Olga Kornievskaia <olga.kornievskaia@gmai=
l.com> wrote:
>>>=20
>>> On Wed, Oct 20, 2021 at 11:54 AM J. Bruce Fields <bfields@fieldses.org>=
 wrote:
>>>>=20
>>>> knfsd has supported server-to-server copy for a couple years (since
>>>> 5.5).  You have set a module parameter to enable it.  I'm getting aske=
d
>>>> when we could turn that parameter on by default.
>>>>=20
>>>> I've got a couple vague criteria: one just general maturity, the other=
 a
>>>> security question:
>>>>=20
>>>> 1. General maturity: the only reports I recall seeing are from testers=
.
>>>> Is anyone using this?  Does it work for them?  Do they find a benefit?
>>>> Maybe we could turn it on by default in one distro (Fedora?) and promo=
te
>>>> it a little and see what that turns up?
>>>>=20
>>>> 2. Security question: with server-to-server copy enabled, you can send
>>>> the server a COPY call with any random address, and the server will
>>>> mount that address, open a file, and read from it.  Is that safe?
>>>=20
>>> How about adding a piece then on the server (a policy) that would only
>>> control that? The concept behind the server-to-server was that servers
>>> might have a private/fast network between them that they would want to
>>> utilize. A more restrictive policy could be to only allow predefined
>>> network space to do the COPY? I know that more work. But sound like
>>> perhaps it might be something that provides more control to the
>>> server.
>>>=20
>>> But as Chuck pointed out perhaps the kerberos piece would make this
>>> concern irrelevant.
>>=20
>> I like the idea of having a server-side policy setting that
>> controls whether s2sc is permitted, and maybe establishes a
>> range of IP addresses allowed to be destination servers.
>=20
> Maybe, but:
>=20
> 	1) Couldn't you get something awfully close to that with
> 	firewall configuration?

Not if the s2sc policy setting is on each export.


> 	2) I'm getting asked why server-side copy isn't on by default.

And your answer to that was "we haven't figured out how to
guarantee security when it's enabled".


> 	So I guess the requirement to set inter_copy_offload_enable is
> 	too much.  How does requiring more complicated configuration
> 	answer that concern?

It answers the concern by letting local administrators choose
to enable or disable s2sc based on their own security needs.


> 	3) There's interest in allowing unprivileged NFS mounts.  That's
> 	more of a security risk than this.  What's the client
> 	maintainers' judgement about unprivileged NFS mounts?  Do they
> 	think that would be safe to allow by default in distros?  If so,
> 	then we're certainly fine here.

Unprivileged mounting seems like a different question to me.
Related, possibly, but not the same. I'd rather leave that
discussion to another thread.


--
Chuck Lever