* [GIT PULL] fs fix for v5.19-rc3
@ 2022-06-15 10:37 Christian Brauner
2022-06-15 16:17 ` pr-tracker-bot
2022-06-15 16:31 ` Linus Torvalds
0 siblings, 2 replies; 4+ messages in thread
From: Christian Brauner @ 2022-06-15 10:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Hey Linus,
/* Summary */
This fixes an issue where we fail to change the group of a file when the caller
owns the file and is a member of the group to change to. This is only relevant
on idmapped mounts. This has originally been reported against [2]. There's a
detailed description in the commit message and regression tests have been added
to xfstests at [1].
Link: https://lore.kernel.org/fstests/20220615092826.2333847-1-brauner@kernel.org [1]
Link: Link: https://github.com/lxc/lxd/issues/10537 [2]
/* Testing */
All patches are based on v5.19-rc1 and have been sitting in linux-next. No
build failures or warnings were observed. The fstests, ltp, and associated
selftests 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.
The following changes since commit f2906aa863381afb0015a9eb7fefad885d4e5a56:
Linux 5.19-rc1 (2022-06-05 17:18:54 -0700)
are available in the Git repository at:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/fs.fixes.v5.19-rc3
for you to fetch changes up to 168f912893407a5acb798a4a58613b5f1f98c717:
fs: account for group membership (2022-06-14 12:18:47 +0200)
Please consider pulling these changes from the signed fs.fixes.v5.19-rc3 tag.
Thanks!
Christian
----------------------------------------------------------------
fs.fixes.v5.19-rc3
----------------------------------------------------------------
Christian Brauner (1):
fs: account for group membership
fs/attr.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GIT PULL] fs fix for v5.19-rc3
2022-06-15 10:37 [GIT PULL] fs fix for v5.19-rc3 Christian Brauner
@ 2022-06-15 16:17 ` pr-tracker-bot
2022-06-15 16:31 ` Linus Torvalds
1 sibling, 0 replies; 4+ messages in thread
From: pr-tracker-bot @ 2022-06-15 16:17 UTC (permalink / raw)
To: Christian Brauner; +Cc: Linus Torvalds, linux-kernel
The pull request you sent on Wed, 15 Jun 2022 12:37:52 +0200:
> git@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/fs.fixes.v5.19-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/979086f5e0066b4eff66e1eee123da228489985c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GIT PULL] fs fix for v5.19-rc3
2022-06-15 10:37 [GIT PULL] fs fix for v5.19-rc3 Christian Brauner
2022-06-15 16:17 ` pr-tracker-bot
@ 2022-06-15 16:31 ` Linus Torvalds
2022-06-16 7:59 ` Christian Brauner
1 sibling, 1 reply; 4+ messages in thread
From: Linus Torvalds @ 2022-06-15 16:31 UTC (permalink / raw)
To: Christian Brauner; +Cc: Linux Kernel Mailing List
On Wed, Jun 15, 2022 at 3:39 AM Christian Brauner <brauner@kernel.org> wrote:
>
> This fixes an issue where we fail to change the group of a file when the caller
> owns the file and is a member of the group to change to. This is only relevant
> on idmapped mounts.
Pulled, but this code makes me go "Eww".
I do get the feeling that maybe we should have some kind of static
type help here, with "unmapped" and "filesystem mapped" uid/gid values
having different types, the same way we have kuid_t vs uid_t for
user-namespace mapping.
Because it feels like the problem here is that "kgid_t" has different
meanings depending on context.
In fact, just within that one function, we have *three* very different kgid_t's:
- the argument to the function is a "kgid_t gid", which has *not*
been mapped into the filesystem mapping (why not?)
- the function itself declares a "kgid_t kgid", which is the inode
group ID mapped into the mount
- it how additionally has that thied "kgid_t mapped_gid", which is
the first 'gid' mapped into the mount
and honestly, I find that hugely confusing. The naming doesn't exactly
clarify things either (ie "gid" is a "kgid_t", not a "git_t", and so
is "kgid" - not helpful).
And being confusing with no type system support isn't a great thing.
So I'm wondering if <linux/mnt_idmapping.h> might be able to do the
same kind of things we do in <linux/uidgid.h>.
NOTE: I did not look into just how hugely painful that would be. Maybe
the above is the rantings of a madman.
Linus
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GIT PULL] fs fix for v5.19-rc3
2022-06-15 16:31 ` Linus Torvalds
@ 2022-06-16 7:59 ` Christian Brauner
0 siblings, 0 replies; 4+ messages in thread
From: Christian Brauner @ 2022-06-16 7:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Wed, Jun 15, 2022 at 09:31:32AM -0700, Linus Torvalds wrote:
> On Wed, Jun 15, 2022 at 3:39 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > This fixes an issue where we fail to change the group of a file when the caller
> > owns the file and is a member of the group to change to. This is only relevant
> > on idmapped mounts.
>
> Pulled, but this code makes me go "Eww".
>
> I do get the feeling that maybe we should have some kind of static
> type help here, with "unmapped" and "filesystem mapped" uid/gid values
> having different types, the same way we have kuid_t vs uid_t for
> user-namespace mapping.
>
> Because it feels like the problem here is that "kgid_t" has different
> meanings depending on context.
>
> In fact, just within that one function, we have *three* very different kgid_t's:
>
> - the argument to the function is a "kgid_t gid", which has *not*
> been mapped into the filesystem mapping (why not?)
>
> - the function itself declares a "kgid_t kgid", which is the inode
> group ID mapped into the mount
>
> - it how additionally has that thied "kgid_t mapped_gid", which is
> the first 'gid' mapped into the mount
>
> and honestly, I find that hugely confusing. The naming doesn't exactly
> clarify things either (ie "gid" is a "kgid_t", not a "git_t", and so
> is "kgid" - not helpful).
>
> And being confusing with no type system support isn't a great thing.
>
> So I'm wondering if <linux/mnt_idmapping.h> might be able to do the
> same kind of things we do in <linux/uidgid.h>.
>
> NOTE: I did not look into just how hugely painful that would be. Maybe
> the above is the rantings of a madman.
I'm actually looking into this and have been for a while. I had thought
about this from the start but just now have time to play with this!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-16 7:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-15 10:37 [GIT PULL] fs fix for v5.19-rc3 Christian Brauner
2022-06-15 16:17 ` pr-tracker-bot
2022-06-15 16:31 ` Linus Torvalds
2022-06-16 7:59 ` Christian Brauner
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.