On Wed, 3 Jan 2024 10:38:09 -0800 Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Wed, 3 Jan 2024 at 10:12, Linus Torvalds > <torva...@linux-foundation.org> wrote: > > > > Much better. Now eventfs looks more like a real filesystem, and less > > like an eldritch horror monster that is parts of dcache tackled onto a > > pseudo-filesystem. > > Oh, except I think you still need to just remove the 'set_gid()' mess. > > It's disgusting and it's wrong, and it's not even what the 'uid' > option does (it only sets the root inode uid). > > If you remount the filesystem with different gid values, you get to > keep both broken pieces. And if it isn't a remount, then setting the > root uid is sufficient. > > I think the whole thing was triggered by commit 49d67e445742, and > maybe the fix is to just revert that commit. > > That commit makes no sense in general, since the default mounting > position for tracefs that the kernel sets up is only accessible to > root anyway. > > Alternatively, just do the ->permissions() thing, and allow access to > the group in the mount options. > > Getting rid of set_gid() would be this attached lovely patch: > > fs/tracefs/inode.c | 83 > ++---------------------------------------------------- > 1 file changed, 2 insertions(+), 81 deletions(-) > > and would get rid of the final (?) piece of disgusting dcache hackery > that tracefs most definitely should not have. > I'll look at that and play with it. I understand VFS much better now that I spent so much time with eventfs. That commit had to do with allowing OTH read access, which is a security issue as the trace files expose a lot of the kernel internals. I think these changes are a bit much for -rc8, don't you? Or do you want all this in before v6.7 is released. I'd be more comfortable with adding these changes in the upcoming merge window, where I can have more time playing with them. -- Steve
