Message ID | 20221212123348.169903-1-brauner@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2216393wrr; Mon, 12 Dec 2022 04:36:28 -0800 (PST) X-Google-Smtp-Source: AA0mqf7aa+oOFiCPdMqRaLcCDmWQEOO4FhjXOuXBl0nqKp4cYd7uVNS6Tg9Ih9Nz2G9XAv2gjHJy X-Received: by 2002:a17:907:1045:b0:7c0:ca94:4631 with SMTP id oy5-20020a170907104500b007c0ca944631mr13233009ejb.30.1670848577024; Mon, 12 Dec 2022 04:36:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670848577; cv=none; d=google.com; s=arc-20160816; b=I0pouvDXUG9nWR3/A4yiVOUO4akX57H3kuXDnQd09BOtsvkGiTqu18OxCzemp03cus YzX+XniqoK9G9w75LkN/knUudr0UFAu4cNhITuxwQ1xu/ngXlajZ5IDY5DqNtr2A7z+8 6j1IywDpJu+QDgIzL1Bx20JToe1YQg8lq2txtjcTkZ0JOPG+JvMRtvQZH1LwSbeVdSeo 4RD7yNMDfmTMNMZB8i5f8aEm6SCi6f8A0Nts0uat5JfpKV+Gbl7EHfFqUUPekhRP5dvW W0YcZ2znVDcDpThdjwmHcrwlivQL79KWFCEYFpH2vG/l2crA9X/wDpbAmRIMJlGw5f9y wqLQ== 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=76PVHP/O21yOYQTQWl2KVA/5/isQIchNIVPu9tc2zcU=; b=TKH1LIpNZaB5v0j6O65EoiViUxtyMhMFTOlRKqjgeAMLMg2P3PF2eTLjJoptAIiKp0 oz/SvUY7rV4PC6FiAjMYj/nhwhqoxyrLTwnOP8tt+X7tjZpk5723lvZLikFWeClwht+T 8KItfrZMIUBdG4RU1N9v/O1VPdz3Yo0F0RNneg+kTWZGYnxO22TQsyLCID92ONCETB65 5ZCsT1gGx0iRkSrVArS7t2BFvGaKH5gNS/k8Ibe2BEsOpHv6Okg5cZQ80flRxZExTmo6 3vckjJNCWPd1FxaZxuATqwny/fVUxOAQcbtyVJqEpP/DhvdZv28Fan1jA2RVvxXQJ6iv oHsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WPElUzUh; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gn26-20020a1709070d1a00b007c0c0cb9f25si6842577ejc.3.2022.12.12.04.35.53; Mon, 12 Dec 2022 04:36:16 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=WPElUzUh; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232350AbiLLMfW (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Mon, 12 Dec 2022 07:35:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232342AbiLLMez (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Dec 2022 07:34:55 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5678A11A17; Mon, 12 Dec 2022 04:34:18 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 18D29B80D0C; Mon, 12 Dec 2022 12:34:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5620C433F0; Mon, 12 Dec 2022 12:34:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670848442; bh=xtdAmCMl29VEatoJ4kmd4nWM9mHIzeabHXzaRNDlt6c=; h=From:To:Cc:Subject:Date:From; b=WPElUzUhbwqbhqrVW/KnFjqhzJKRMMF65RQAROvEyxu/tMyQ+nqOFDwInqgywOwcu /WgDrgd/qBYJZ4sTrhRjGaPizPRhHNXvFFbWRiGNYpN8Y/V3vt9ghUMxJafXu7BwFL 9Hm+y9KFoesoEUjeuMlC9qKA3sy5rk/MNNsxOg5FjaIYrNMp6G0NVNhgVFrCM3h0TD o/5k91AyaETIcv9oNwYTktIA7IuYxnU6UPKs3mPON4PL9TIbR1JC4Gq9U+eBPDjmHa /JTiBbzOLEREZsHcJlYEO8GpkrcisMyiGW3U5PBJJeMY5TIrVnam+dQz7/ZBlq+vz/ t2B+7f09IcjAw== From: Christian Brauner <brauner@kernel.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Christian Brauner <brauner@kernel.org>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [GIT PULL] vfsuid updates for v6.2 Date: Mon, 12 Dec 2022 13:33:48 +0100 Message-Id: <20221212123348.169903-1-brauner@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5064; i=brauner@kernel.org; h=from:subject; bh=xtdAmCMl29VEatoJ4kmd4nWM9mHIzeabHXzaRNDlt6c=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMSRPl18yk8c2re+m1IQ6/dWb3v/QsvUzm7D8yNXAeH+B3Nip HtPndJSyMIhxMciKKbI4tJuEyy3nqdhslKkBM4eVCWQIAxenAExknS0jw+sQtruzil4/Ck7/M+lLiH pmXqLjpv/rrud7xEyZL79y5k9Ghm+ZBTeeHY38eOxhUcOfzByLA6J//P16/R8+3eOp/WPDJkYA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752011717178029875?= X-GMAIL-MSGID: =?utf-8?q?1752011717178029875?= |
Series |
[GIT,PULL] vfsuid updates for v6.2
|
|
Pull-request
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git tags/fs.vfsuid.conversion.v6.2Message
Christian Brauner
Dec. 12, 2022, 12:33 p.m. UTC
Hey Linus, /* Summary */ Last cycle we introduced the vfs{g,u}id_t types and associated helpers to gain type safety when dealing with idmapped mounts. That initial pull request back then already converted a lot of places over but there were still some left, This pull request converts all remaining places that still make use of non-type safe idmapping helpers to rely on the new type safe vfs{g,u}id based helpers. Afterwards it removes all the old non-type safe helpers. Note that this pull request has the setgid inheritance branch merged in as the setgid inheritance branch unifies multiple open-coded checks into a single helper making the conversion here easier. I've sent a pull request for that work rearlier so it's on the list and in your inbox before this one. The lore url is: https://lore.kernel.org/lkml/20221212112053.99208-1-brauner@kernel.org In case you don't want to pull "setgid inheritance updates for v6.2" but still would like to pull the remaining vfs{g,u}id_t conversions (That would be greatly appreciated as it gets rid of duplicated functionality between the different helpers.) I prepared the tag fs.vfsuid.conversion.standalone.v6.2 This tag only contains all the vfs{g,u}id_t patches without any of the "setgid inheritance updates for v6.2" patches. ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git tags/fs.vfsuid.conversion.standalone.v6.2 /* Testing */ clang: Ubuntu clang version 15.0.2-1 gcc: gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0 All patches are based on v6.1-rc1 and have been sitting in linux-next. No build failures or warnings were observed. The vfsuid conversionn portion passes all old and new tests in fstests, selftests, and LTP pass without regressions. /* Conflicts */ At the time of creating this PR no merge conflicts were reported from linux-next and no merge conflicts showed up doing a test-merge with current mainline. /* Conflicts */ At the time of creating this PR no merge conflicts were reported from linux-next and no merge conflicts showed up doing a test-merge with current mainline. The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780: Linux 6.1-rc1 (2022-10-16 15:36:24 -0700) are available in the Git repository at: ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git tags/fs.vfsuid.conversion.v6.2 __Alternatively__, a standalone version without the setgid patches merged in can be found at: ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git tags/fs.vfsuid.conversion.standalone.v6.2 for you to fetch changes up to eb7718cdb73c6b0c93002f8f73f4dd4701f8d2bb: fs: remove unused idmapping helpers (2022-10-26 10:03:34 +0200) Please consider pulling these changes from the signed fs.vfsuid.conversion.v6.2 or fs.vfsuid.conversion.standalone.v6.2 tag. Thanks! Christian ---------------------------------------------------------------- fs.vfsuid.conversion.v6.2 ---------------------------------------------------------------- Amir Goldstein (2): ovl: remove privs in ovl_copyfile() ovl: remove privs in ovl_fallocate() Christian Brauner (12): attr: add in_group_or_capable() fs: move should_remove_suid() attr: add setattr_should_drop_sgid() attr: use consistent sgid stripping checks mnt_idmapping: add missing helpers fs: use type safe idmapping helpers caps: use type safe idmapping helpers apparmor: use type safe idmapping helpers ima: use type safe idmapping helpers fuse: port to vfs{g,u}id_t and associated helpers ovl: port to vfs{g,u}id_t and associated helpers fs: remove unused idmapping helpers Documentation/trace/ftrace.rst | 2 +- fs/attr.c | 74 +++++++++++++++++++++++--- fs/coredump.c | 4 +- fs/exec.c | 16 +++--- fs/fuse/acl.c | 2 +- fs/fuse/file.c | 2 +- fs/inode.c | 72 ++++++++++++-------------- fs/internal.h | 10 +++- fs/namei.c | 40 +++++++-------- fs/ocfs2/file.c | 4 +- fs/open.c | 8 +-- fs/overlayfs/file.c | 28 ++++++++-- fs/overlayfs/util.c | 9 +++- fs/remap_range.c | 2 +- fs/stat.c | 7 ++- include/linux/fs.h | 36 +------------ include/linux/mnt_idmapping.h | 100 ++++++++++++------------------------ kernel/capability.c | 4 +- security/apparmor/domain.c | 8 +-- security/apparmor/file.c | 4 +- security/apparmor/lsm.c | 25 ++++++--- security/commoncap.c | 51 +++++++++--------- security/integrity/ima/ima_policy.c | 34 ++++++------ 23 files changed, 289 insertions(+), 253 deletions(-)
Comments
On Mon, Dec 12, 2022 at 4:34 AM Christian Brauner <brauner@kernel.org> wrote: > > This pull request converts all remaining places that still make use of non-type > safe idmapping helpers to rely on the new type safe vfs{g,u}id based helpers. > Afterwards it removes all the old non-type safe helpers. So I've pulled this, but I'm not entirely happy about some of those crazy helpers. In particular, the whole "ordering" helpers are really not something that should be used in general, I feel. I'm talking about vfsuid_gt_kuid() and friends - it's an entirely insane operation and makes no sense at all. Yes, yes, I understand why they exist (those crazy IMA rules), but I feel that those functions *really* shouldn't be exposed to anybody else. IOW, making those insane functions available in <linux/idmapping.h> really seems wrong to me. They are crazy special cases, and I think they should exist purely in that crazy ima_security file. Again - I've pulled this, but I'm hoping to see a future commit that limits that craziness to the only user, in the hope that this disease will never spread. Linus
The pull request you sent on Mon, 12 Dec 2022 13:33:48 +0100:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git tags/fs.vfsuid.conversion.standalone.v6.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e4236f97688afc21151bfc050acfce9ac3b56f6b
Thank you!
On Mon, Dec 12, 2022 at 07:28:59PM -0800, Linus Torvalds wrote: > On Mon, Dec 12, 2022 at 4:34 AM Christian Brauner <brauner@kernel.org> wrote: > > > > This pull request converts all remaining places that still make use of non-type > > safe idmapping helpers to rely on the new type safe vfs{g,u}id based helpers. > > Afterwards it removes all the old non-type safe helpers. > > So I've pulled this, but I'm not entirely happy about some of those > crazy helpers. > > In particular, the whole "ordering" helpers are really not something > that should be used in general, I feel. I'm talking about > vfsuid_gt_kuid() and friends - it's an entirely insane operation and > makes no sense at all. Oh yes, I very much agree. > > Yes, yes, I understand why they exist (those crazy IMA rules), but I I would've really liked to have avoided their existence altogether but I have no clear idea what ima is doing with these comparisons. And everytime we do wider scoped vfs work I spend about 1 or 2 good weeks in security/ just to understand what all the various security modules do, audit callchains and then come up with something that doesn't break half of them. And often this means unpleasant compromises in the vfs layer which I really don't like. And just to be clear, I don't want to be on of those "LSMs are bad" people. I do really think they provide additional value. But I think it's fair to acknowledge that the hook infrastructure with multiple LSMs makes the vfs and developers pay when reworking codepaths. And the fact that some things that are LSM-like (ima etc.) have separate hooks doesn't help either. > feel that those functions *really* shouldn't be exposed to anybody > else. > > IOW, making those insane functions available in <linux/idmapping.h> > really seems wrong to me. They are crazy special cases, and I think > they should exist purely in that crazy ima_security file. > > Again - I've pulled this, but I'm hoping to see a future commit that > limits that craziness to the only user, in the hope that this disease > will never spread. Let me see what I can do about this. Hopefully I can still find something during the merge window.
On 13/12/2022 04.28, Linus Torvalds wrote: > On Mon, Dec 12, 2022 at 4:34 AM Christian Brauner <brauner@kernel.org> wrote: >> >> This pull request converts all remaining places that still make use of non-type >> safe idmapping helpers to rely on the new type safe vfs{g,u}id based helpers. >> Afterwards it removes all the old non-type safe helpers. > > So I've pulled this, but I'm not entirely happy about some of those > crazy helpers. > > In particular, the whole "ordering" helpers are really not something > that should be used in general, I feel. I'm talking about > vfsuid_gt_kuid() and friends - it's an entirely insane operation and > makes no sense at all. > > Yes, yes, I understand why they exist (those crazy IMA rules), but I > feel that those functions *really* shouldn't be exposed to anybody > else. > > IOW, making those insane functions available in <linux/idmapping.h> > really seems wrong to me. They are crazy special cases, and I think > they should exist purely in that crazy ima_security file. Yeah. Aside from assigning any semantics to < or > of [ug]ids, which is something IMA apparently wants to do, taking the address of a static inline in the first place is a code smell; that obviously forces the compiler to emit a copy in the current TU. But the code compares stored pointers to addresses of those static inlines, which would be completely broken if this didn't happen to all be contained in a single TU. That's quite subtle, and probably fowner_op would be better as an enum. Rasmus