All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>
Subject: Re: [PATCH v1 1/2] vfs: Add new setgid_create_umask test
Date: Mon, 25 Jul 2022 16:20:20 +0200	[thread overview]
Message-ID: <20220725142020.rtc2mgfhcw47v4t4@wittgenstein> (raw)
In-Reply-To: <91470460-44cd-90a3-2e95-8e0fbefcd9ad@fujitsu.com>

On Mon, Jul 25, 2022 at 07:55:23AM +0000, xuyang2018.jy@fujitsu.com wrote:
> 
> on  2022/05/21 0:04, Yang Xu wrote:
> > The current_umask() is stripped from the mode directly in the vfs if the
> > filesystem either doesn't support acls or the filesystem has been
> > mounted without posic acl support.
> > 
> > If the filesystem does support acls then current_umask() stripping is
> > deferred to posix_acl_create(). So when the filesystem calls
> > posix_acl_create() and there are no acls set or not supported then
> > current_umask() will be stripped.
> > 
> > This patch is also designed to test kernel patchset behaviour
> > "move S_ISGID stripping into the vfs"
> > https://patchwork.kernel.org/project/linux-fsdevel/list/?series=635692
> 
> The kernel patch has been merged into linux-next branch[1].
> 
> Does anyone review this fstests patch or give some comment?
> 
> I plan to remove setgid_create_umask_idmapped_in_userns and 
> setgid_create_umask_idmapped cases because they doesn't trigger bug.
> 
> Just treat it  as a kernel regression test ie 31c01ce18 ("generic: add 
> test for tmpfs POSIX ACLs") format.
> 
> CC Christian to confirm that whether need to test idmapped and 
> idmapped_in_userbs situation .

You've also sent a patch to LTP I saw which is good. I'm not completely
sure why you want to remove setgid_create_umask_idmapped{_in_userns}.
But as long as we have tests for setgid stripping on idmapped mounts I'm
fine with this.

Christian

  reply	other threads:[~2022-07-25 14:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 16:04 [PATCH v1 1/2] vfs: Add new setgid_create_umask test Yang Xu
2022-05-20 16:04 ` [PATCH v1 2/2] vfs: Add new setgid_create_acl test Yang Xu
2022-07-16 16:12 ` [PATCH v1 1/2] vfs: Add new setgid_create_umask test Zorro Lang
2022-07-19  7:20   ` xuyang2018.jy
2022-07-25  7:55 ` xuyang2018.jy
2022-07-25 14:20   ` Christian Brauner [this message]
2022-07-26  8:20     ` xuyang2018.jy
2022-07-26  9:31     ` [PATCH v2 " Yang Xu
2022-07-26  9:31       ` [PATCH v2 2/2] vfs: Add new setgid_create_acl test Yang Xu
2022-08-29 13:20         ` Christian Brauner
2022-08-30  9:03           ` xuyang2018.jy
2022-08-29 13:52         ` Christian Brauner
2022-08-30  9:06           ` xuyang2018.jy
2022-08-15 10:02       ` [PATCH v2 1/2] vfs: Add new setgid_create_umask test xuyang2018.jy
2022-08-29  1:14         ` 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=20220725142020.rtc2mgfhcw47v4t4@wittgenstein \
    --to=brauner@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=xuyang2018.jy@fujitsu.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.