Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp8007051rwn; Wed, 14 Sep 2022 07:39:48 -0700 (PDT) X-Google-Smtp-Source: AA6agR6BHBDOS8VaRf16Y+WcBIm1w6maApuG/yOZi4b8ZWm6leJXzvj+tsHwHgT9v50hNVZ1/peT X-Received: by 2002:a17:90b:1d0e:b0:202:809c:2d70 with SMTP id on14-20020a17090b1d0e00b00202809c2d70mr5156395pjb.14.1663166387790; Wed, 14 Sep 2022 07:39:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663166387; cv=none; d=google.com; s=arc-20160816; b=0pLs0aQFbWi4JfEPfPBFy4iZN9jPhuE67/9rIt6JoQ7V4byHfqfhReP4nH8rV/sFG1 0VN+fDM0Hf++pdIovM7H/5M9JeTmbANLHvxD0BB5UOX/Gh0idjEjceReT183l8GeXiFn bGX9bkd9ptS3GD0qxG+Kk/irN7XVuDVLQVm7xjJdF3pGuJr6Heg8U1fgNHXYQCmygM0t 9X8fpeFj2C8sUJo81Fyo2ZDex+cnLaKEnzLSGMjVmNBnuGQnsm14fCB6lF7CkTYXGogu U0HWMCsESzXKPHAXa0t3hxjpgPuvm6+AfDuKJG+58cAEDZAUiSgEZR0IcJLLETIdNIeY gKqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=z5Z+1Ej59+eqFNlmwdCmpNW1qUH5otodDaXBtgZAZzE=; b=tTxGShhp3nbX7lpTJQYNeyg0LebbC/MsPHPaVYAcOP/R5AJvzzgYuWrwJe4xfuuetA laUixo5X3yYqUTjXA2JAeMOErQ3sd3tU7rjxBWaI48wfJTvzxXAeRLEp5ky/Bpe0XNJP hDdbJW2UK9SqmEOrTIDsEYkmYJ7cKtcgKsTApVB1miIiZq1Deq1Cvlb17WvS5rgfWG7k w7nT3bpQEOO7M4RlbTfrN4WKUT5pha0WBqv6OawnRrkRGtgWCDBvi0AEtgV2Nv8BWTdw 9AYG93omyQxxlLmXmhYvpIbX8aNVkkmQv7QKrG/VXtU7cScnnoDWMVs4160oW7V2Mlra llzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kD9aDfcD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b4-20020a170902d50400b0017835995e40si10022928plg.414.2022.09.14.07.39.34; Wed, 14 Sep 2022 07:39:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kD9aDfcD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229636AbiINO1R (ORCPT + 99 others); Wed, 14 Sep 2022 10:27:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbiINO1D (ORCPT ); Wed, 14 Sep 2022 10:27:03 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 755711B780 for ; Wed, 14 Sep 2022 07:27:01 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id z12so7673863wrp.9 for ; Wed, 14 Sep 2022 07:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date; bh=z5Z+1Ej59+eqFNlmwdCmpNW1qUH5otodDaXBtgZAZzE=; b=kD9aDfcDoRGyBlkIlekXGYPic+zFGhEuvXLgE7RPDDQrH9Nk9lKfbi+viiaRSLJcMl n622s2zPHFHcmELmvdXhIeyKhPDWJkjWnpdWurHJ95jjznmGVAslGY/EUXmPAwwT3oMX P7MJczcWWWYb0MlKDm57MFBQk4KWLHuXEejyidOB3yMPnmKXdl9uu1oF9xoSAo6hsQBr 2GZG8aIPoMT5EtkYouvzEFPNreLIafFBN8VNbjAIxbBUZ5wRmBohlMb3Ayiw0ppa36qX qQxMX3LSpZ9OdwTDKvaHGmactnVeOh9WeC2eNWe9TukEYeN6irZTsDr0gszv0SygmvzA UQyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date; bh=z5Z+1Ej59+eqFNlmwdCmpNW1qUH5otodDaXBtgZAZzE=; b=3ar+FurF09CLtcK16s8RRQ1YID+HrPi810h7grFHkspbfPK9dmwCgX/uDvYvM63se6 aUjqyOPHUergkrokgPm1uNdCzg9ED/UqPhU45h2Cdwkk8Rnw/Gz1PDM5wrmG91IOCx1O HiprzieklcCymNA1DXqretVBIw/tCgGx2ZZmBRuVWpmPdphyTJa23bAg/q88YgxIowVY vrCphrX+u3FXVqQfPqSwUZdr2KGJF2Yh7V2QvsRHedSYlHdxs5t+lVNPFDSfb33hSr11 nO4LVyhKmTuCgchvW9QGSF+jgIYFw1ZDH0gpEO2VhrqABNY7EWGmNDZHvrI3G7VXlF2w EGYQ== X-Gm-Message-State: ACgBeo2Q2VCvpZe/aKJaT9ukJZ8Q5MVobT0vre7diVieAIQpvhDdnCBx 84MUikOC+aCoDzJ5sOUurol1HA== X-Received: by 2002:a5d:60ca:0:b0:228:d77e:4b25 with SMTP id x10-20020a5d60ca000000b00228d77e4b25mr22118423wrt.139.1663165619449; Wed, 14 Sep 2022 07:26:59 -0700 (PDT) Received: from localhost ([2a00:79e0:9d:4:b3a5:6d13:189f:405f]) by smtp.gmail.com with ESMTPSA id o22-20020a05600c511600b003a5b6086381sm18573322wms.48.2022.09.14.07.26.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 07:26:58 -0700 (PDT) From: Jann Horn To: Miklos Szeredi , Eric Biederman Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] fuse: Remove user_ns check for FUSE_DEV_IOC_CLONE Date: Wed, 14 Sep 2022 16:26:32 +0200 Message-Id: <20220914142632.2016571-1-jannh@google.com> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 8ed1f0e22f49e ("fs/fuse: fix ioctl type confusion") fixed a type confusion bug by adding an ->f_op comparison. Based on some off-list discussion back then, another check was added to compare the f_cred->user_ns. This is not for security reasons, but was based on the idea that a FUSE device FD should be using the UID/GID mappings of its f_cred->user_ns, and those translations are done using fc->user_ns, which matches the f_cred->user_ns of the initial FUSE device FD thanks to the check in fuse_fill_super(). See also commit 8cb08329b0809 ("fuse: Support fuse filesystems outside of init_user_ns"). But FUSE_DEV_IOC_CLONE is, at a higher level, a *cloning* operation that copies an existing context (with a weird API that involves first opening /dev/fuse, then tying the resulting new FUSE device FD to an existing FUSE instance). So if an application is already passing FUSE FDs across userns boundaries and dealing with the resulting ID mapping complications somehow, it doesn't make much sense to block this cloning operation. I've heard that this check is an obstacle for some folks, and I don't see a good reason to keep it, so remove it. Signed-off-by: Jann Horn --- @Eric: Does this look reasonable to you? I dug through my old mails, and in the off-list discussion back then, Linus and you were in favor of adding this check. fs/fuse/dev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index 51897427a5346..920480054e1dc 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -2266,8 +2266,7 @@ static long fuse_dev_ioctl(struct file *file, unsigne= d int cmd, * Check against file->f_op because CUSE * uses the same ioctl handler. */ - if (old->f_op =3D=3D file->f_op && - old->f_cred->user_ns =3D=3D file->f_cred->user_ns) + if (old->f_op =3D=3D file->f_op) fud =3D fuse_get_dev(old); =20 if (fud) { base-commit: 3245cb65fd91cd514801bf91f5a3066d562f0ac4 --=20 2.37.2.789.g6183377224-goog