All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. R. Okajima" <hooanon05g@gmail.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: amir73il@gmail.com, linux-integrity@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-unionfs@vger.kernel.org,
	miklos@szeredi.hu, Stefan Berger <stefanb@linux.ibm.com>,
	syzbot+a67fc5321ffb4b311c98@syzkaller.appspotmail.com,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, Tyler Hicks <code@tyhicks.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH] fs: Pass AT_GETATTR_NOSEC flag to getattr interface function
Date: Fri, 08 Dec 2023 06:10:18 +0900	[thread overview]
Message-ID: <1734.1701983418@jrotkm2> (raw)
In-Reply-To: <20231002125733.1251467-1-stefanb@linux.vnet.ibm.com>

Stefan Berger:
> When vfs_getattr_nosec() calls a filesystem's getattr interface function
> then the 'nosec' should propagate into this function so that
> vfs_getattr_nosec() can again be called from the filesystem's gettattr
> rather than vfs_getattr(). The latter would add unnecessary security
> checks that the initial vfs_getattr_nosec() call wanted to avoid.
> Therefore, introduce the getattr flag GETATTR_NOSEC and allow to pass
> with the new getattr_flags parameter to the getattr interface function.
> In overlayfs and ecryptfs use this flag to determine which one of the
> two functions to call.

You are introducing two perfectly identical functions.
ecryptfs_do_getattr() and ovl_do_getattr().
Why don't you provide one in a common place, such like
include/linux/fs_stack.h?


J. R. Okajima

      parent reply	other threads:[~2023-12-07 21:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 12:57 [PATCH] fs: Pass AT_GETATTR_NOSEC flag to getattr interface function Stefan Berger
2023-10-02 13:22 ` Amir Goldstein
2023-10-02 13:52   ` Stefan Berger
2023-10-03 13:38   ` Christian Brauner
2023-10-10  1:14     ` Mimi Zohar
2023-10-10  8:35 ` Christian Brauner
2023-11-06 19:44   ` Stefan Berger
2023-11-08  9:20     ` Christian Brauner
2023-12-07 21:10 ` J. R. Okajima [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1734.1701983418@jrotkm2 \
    --to=hooanon05g@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=code@tyhicks.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=stefanb@linux.ibm.com \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=syzbot+a67fc5321ffb4b311c98@syzkaller.appspotmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.