From: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
To: Christian Brauner <brauner@kernel.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"david@fromorbit.com" <david@fromorbit.com>,
"djwong@kernel.org" <djwong@kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"jlayton@kernel.org" <jlayton@kernel.org>
Subject: Re: [PATCH v7 4/4] ceph: Remove S_ISGID stripping code in ceph_finish_async_create
Date: Tue, 26 Apr 2022 08:43:59 +0000 [thread overview]
Message-ID: <6267BF2E.70504@fujitsu.com> (raw)
In-Reply-To: <20220426071413.75mgcayybdb3cwgw@wittgenstein>
on 2022/4/26 15:14, Christian Brauner wrote:
> On Tue, Apr 26, 2022 at 12:19:52PM +0800, Yang Xu wrote:
>> Previous patches moved sgid stripping exclusively into the vfs. So
>> manual sgid stripping by the filesystem isn't needed anymore.
>>
>> Reviewed-by: Xiubo Li<xiubli@redhat.com>
>> Reviewed-by: Christian Brauner (Microsoft)<brauner@kernel.org>
>> Signed-off-by: Yang Xu<xuyang2018.jy@fujitsu.com>
>> ---
>
> Since this is a very sensitive patch series I think we need to be
> annoyingly pedantic about the commit messages. This is really only
> necessary because of the nature of these changes so you'll forgive me
> for being really annoying about this. Here's what I'd change the commit
> messages to:
>
> ceph: rely on vfs for setgid stripping
>
> Now that we finished moving setgid stripping for regular files in setgid
> directories into the vfs, individual filesystem don't need to manually
> strip the setgid bit anymore. Drop the now unneeded code from ceph.
This seems better, thanks.
>
>
>> fs/ceph/file.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>> index 6c9e837aa1d3..8e3b99853333 100644
>> --- a/fs/ceph/file.c
>> +++ b/fs/ceph/file.c
>> @@ -651,10 +651,6 @@ static int ceph_finish_async_create(struct inode *dir, struct dentry *dentry,
>> /* Directories always inherit the setgid bit. */
>> if (S_ISDIR(mode))
>> mode |= S_ISGID;
>
> (Frankly, this ideally shouldn't be necessary as well, i.e. it'd be
> great if that part would've been done by the vfs already too but it's
> not as security sensitive as setgid stripping for regular files.)
Maybe we can just add mode_add_sgid api into vfs_prepare_mode in the
future or only just add mode_add_sgid into do_mkdirat?
static inline umode_t vfs_prepare_mode(struct user_namespace *mnt_userns,
const struct inode *dir, umode_t mode)
{
mode = mode_strip_sgid(mnt_userns, dir, mode);
if (!IS_POSIXACL(dir))
mode &= ~current_umask();
mode = mode_add_sgid(dir, mode)
return mode;
}
fs/inode.c
umodet mode_add_sgid(const struct inode *dir, umode_t mode)
{
if (dir && dir->i_mode & S_ISGID && S_ISDIR(mode))
mode |= S_ISGID;
return mode;
}
Then we can remove "mode |= S_ISGID" code in inode_init_owner after we
check all places called inode_init_owner.
But now, let's finished S_ISGID stripping patchset firstly.
next prev parent reply other threads:[~2022-04-26 9:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 4:19 [PATCH v7 1/4] fs: move sgid stripping operation from inode_init_owner into mode_strip_sgid Yang Xu
2022-04-26 4:19 ` [PATCH v7 2/4] fs: Add missing umask strip in vfs_tmpfile Yang Xu
2022-04-26 4:19 ` [PATCH v7 3/4] fs: strip file's S_ISGID mode on vfs instead of on underlying filesystem Yang Xu
2022-04-26 5:21 ` Darrick J. Wong
2022-04-26 8:34 ` Christian Brauner
2022-04-26 4:19 ` [PATCH v7 4/4] ceph: Remove S_ISGID stripping code in ceph_finish_async_create Yang Xu
2022-04-26 7:14 ` Christian Brauner
2022-04-26 8:43 ` xuyang2018.jy [this message]
2022-04-26 7:06 ` [PATCH v7 1/4] fs: move sgid stripping operation from inode_init_owner into mode_strip_sgid Christian Brauner
2022-04-26 7:39 ` xuyang2018.jy
2022-04-26 8:39 ` Christian Brauner
2022-04-26 9:22 ` xuyang2018.jy
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=6267BF2E.70504@fujitsu.com \
--to=xuyang2018.jy@fujitsu.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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.