From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7092C83F10 for ; Thu, 31 Aug 2023 09:19:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 108638E0013; Thu, 31 Aug 2023 05:19:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B8E18D0001; Thu, 31 Aug 2023 05:19:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0FE78E0013; Thu, 31 Aug 2023 05:19:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E27518D0001 for ; Thu, 31 Aug 2023 05:19:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AA10C1601AE for ; Thu, 31 Aug 2023 09:19:35 +0000 (UTC) X-FDA: 81183851910.09.72E514C Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf28.hostedemail.com (Postfix) with ESMTP id E9395C0019 for ; Thu, 31 Aug 2023 09:19:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=P9C64WyK; spf=pass (imf28.hostedemail.com: domain of hughd@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693473573; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4Cbrhq38paxu0xySM9f3IPWoiWkUTnk9D5gKI2jM47E=; b=o9vXPJ13FqSlyrWPGR1uPtwdH0Oq7hfN/6i7hMHXV1FhrBzPs2V0NQGB3GybttC+bbLLvt hCCHnsRiSeZUOy4HtijAiVOXl9yZgWHNRyaj4HvwSqTkTgZiV1dHavsMBggyIUQ+u8/WV/ XDImLdMla8AATodMNzAg7UNGcmh1amw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693473574; a=rsa-sha256; cv=none; b=5wY2synF9Hvvh6F3mVgT/8mb7VaQjWdUI3Tx+3Q5Wvuli7mZmKCcjJn8jhL6wlYNRCbler OEkG0RQV5WBH8NjKuxQlphT5OpDK0mpfw2BxVqgmKoXDy6J+rHcifAhftEN0UoACn9IkHu N77hW8kvz0w0ApkOhEUYGoMsaORAXbM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=P9C64WyK; spf=pass (imf28.hostedemail.com: domain of hughd@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-58ca499456dso7206157b3.1 for ; Thu, 31 Aug 2023 02:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693473573; x=1694078373; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=4Cbrhq38paxu0xySM9f3IPWoiWkUTnk9D5gKI2jM47E=; b=P9C64WyKtI9UTIZx1si9JOJS+GSuDvMm71xVq/SvwdS+UwlxmHlXVnwa4ajIrtNmCi 4UsX/G6saESebc3oae4mPUeI3WZz+2Q2otHuq/J5ISgx7MoEkaovz36GfmgyAWvTRfYM 59sp2qABnOnov75vI3CiJyEMrsr5K/gHx/vNpzXCJ/MUzaCQNpsnNlGoL5TzACq1uniC pwOdEMTgAeGUeFKFaJ4C+eJWQXvbKPgqduGsUDf1O+4gEnYgIa59PHma7nYCmwHUfffA KisAtiq6p06r8NVqhQDX6rEaI5HlV5PDT3iefBgdPq70yHUW2q6v9aUj/pWZiGuJEqyn PyBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693473573; x=1694078373; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4Cbrhq38paxu0xySM9f3IPWoiWkUTnk9D5gKI2jM47E=; b=MsFU9egKttV67uJGQasvqxvE0GGlbLctErQFRaUGJJfDn7fJm56oJ1GqRiPa4eRJy2 q1YHyIteXNDVf4XqI4PfkwbJbNEo3qNOb73vkTcxdf6c/IXn9O24aU4kR/A2yzCyvRR2 kSivU+XSvNcrjJtSLGWpcGfkrg34ZLKA57T1GIDOfr3tFxwI/kXPv7nzsIbDvGCJ3fzb P0xFKSMoUSuNZ6Qns88UFcQJbxTsDUKEIBEU1MquYOaxn2x6xQn7XjXye7rDoSkVNtJ6 sEXffOrwmC0TSgoQwFxnBpkctmJ6PCWTjLE5zVn5G5kRR0BFaMIWUNbtX3XM097/+J4a kbmg== X-Gm-Message-State: AOJu0YyvKb6TdMqBffmgtV9JahnuAR35FF+jTx+61Qr8bh02sbjesCBc ZOCkzNzHI/eXIRDRu+rGRZcG0w== X-Google-Smtp-Source: AGHT+IFThEVwm5PdQ/QiEIcAo8WglpblQRWl0MFWrXvjJuNLD0Kr5QEj6RbRV7hyCCkRaORZMOKarA== X-Received: by 2002:a0d:c483:0:b0:592:9236:9460 with SMTP id g125-20020a0dc483000000b0059292369460mr4914737ywd.31.1693473572920; Thu, 31 Aug 2023 02:19:32 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id i185-20020a8191c2000000b00583e52232f1sm293607ywg.112.2023.08.31.02.19.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 02:19:32 -0700 (PDT) Date: Thu, 31 Aug 2023 02:19:20 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Paul Moore cc: Mimi Zohar , Al Viro , Christian Brauner , Hugh Dickins , Andrew Morton , linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org, linux-mm@kvack.org, linux-integrity@vger.kernel.org Subject: Re: LSM hook ordering in shmem_mknod() and shmem_tmpfile()? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: E9395C0019 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 83g13uyjhonggge1cooo4qmpbdyqcnin X-HE-Tag: 1693473573-478148 X-HE-Meta: U2FsdGVkX1866uz/LMsHK9Jo3zXfvgY7+rZsRAtxyfCSYjBmCMOByqLEl59vHSFDpYlLZ6DAIm1STYThegd9De0j/kFuVS240DUvu+vSNcBzZ9AIDW0BXK3vrWjYnVyZZoSlymn9lpf/kdaICxBUzhjy39M9DL8t28Y+LvcGdZpMbU3TW9zEg4FNFy+ziN3QwlA7XjzWbZQ5sY3vsjOREygoj//kTFVzFXbzjtbdiKjDhEQgZDoFerrP0fC7PZpaAib/a2E5Gd/DRmE0HwDMXUFDtdRtFIlUMlNLEEPNcaBLRNt2R/XApXeEd/uQHQWryva2PWs5XDsgDTg+TRZDwu6XLvcLBT6/Kl4ZAU46D9I/iW1BDs1je8x1PRISHNb0CbAKztd08St7hjHp3dDKO/BuixxOgMY7veS48QP4acVl3URkaiO8CR/39La7ZxprLye92eN6iLdgGA1SiuKxbw3UKUGdHycX/rTUpc0bExpMkTyG75cVEfjRK5jAr8a/WWVYt6u2oCqURsnDbL/NTNTErmpgoLFzqAVRoPB59BmxWhcIDCjC3EuIxCE+Rjs7Ccdy5JUr6ySL7yRI/5Rw0y2PZdjZhUYJtrCLYR0lzvDF8alcVzVhGl/afcSuQn6Je0TzY8w8Hzk+n8Vdg70MXB8YgM4KBvYE7AD0QLwiu2LfWjSpzAENK/ObNYwhRreoPd/pUK9/1+N4Id/olvmFhE6v/IMO/oWgNpRtqhO81dVNXkIscCPkWXpiBZKylHq47iMWsAk46uLSJmJZQkX89NVXQIJy3rpmdRxIVYzZtIODHhEiSQTS3bUoXMb8RFPGwlaYESemUUkBkLVC2LlCaOzu8bMw3X2NEd4dlY5v+8hdRyynKCW7ZSk1lf7uHNfwmAODig9KKrXSSHBD20STNZHDPF0M2jC6jjClVPRJZCUvYGg3+JKTbrX6SONnXpKuY1BMraCtRj2ModvGS2D 8eRsGH+e WrHd04UECxvGcOMOS7REX/zTHfgNhpftWrXAiRT70TuHxC1WfIQFgWrdwUH3YkbdmvOgF/MWZeDwSAbM3+OAt+FA6gQOjY7sFIjaWmc8fxojiBH3U5Y+OIhhIMz2m+YrYTSMpCFK/1UxECDognHCbIT7pjyV+fkgwen0Qc0rO0CFwnyxX2BW4n3U9bKZqEGL9EGIl3vgRaB7eeAXSNFPu8fRDdDCszykvnNjSKtYMJQiTRD+fgBBw00jGp7vr9NPhg2nh12zkWvz/lPA0+ZkBFVkfSFs2yKMZ8kRlWQbKlc7b8ffi6z9aMwC2B3oWGNNGhL87q8kMHowbBLSvJedspLqpW4R/sTQDzaoBn6pQIMQXZPdNRYgu3FvDJktheMpFQwIv0t7ZkcgUbs9G3PpjvL0EWbl/FROi9MTS6Y9khlDflg4f13YEMjOYHZPJkVKPTU/7 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 30 Aug 2023, Paul Moore wrote: > Hello all, > > While looking at some recent changes in mm/shmem.c I noticed that the > ordering between simple_acl_create() and > security_inode_init_security() is different between shmem_mknod() and > shmem_tmpfile(). In shmem_mknod() the ACL call comes before the LSM > hook, and in shmem_tmpfile() the LSM call comes before the ACL call. > > Perhaps this is correct, but it seemed a little odd to me so I wanted > to check with all of you to make sure there is a good reason for the > difference between the two functions. Looking back to when > shmem_tmpfile() was created ~2013 I don't see any explicit mention as > to why the ordering is different so I'm looking for a bit of a sanity > check to see if I'm missing something obvious. > > My initial thinking this morning is that the > security_inode_init_security() call should come before > simple_acl_create() in both cases, but I'm open to different opinions > on this. Good eye. The crucial commit here appears to be Mimi's 3.11 commit 37ec43cdc4c7 "evm: calculate HMAC after initializing posix acl on tmpfs" which intentionally moved shmem_mknod()'s generic_acl_init() up before the security_inode_init_security(), around the same time as Al was copying shmem_mknod() to introduce shmem_tmpfile(). I'd have agreed with you, Paul, until reading Mimi's commit: now it looks more like shmem_tmpfile() is the one to be changed, except (I'm out of my depth) maybe it's irrelevant on tmpfiles. Anyway, I think it's a question better answered by Mimi and Al. Thanks, Hugh