[PATCH v6 24/40] fs: make helpers idmap mount aware
Anton Altaparmakov
anton at tuxera.com
Mon Apr 12 12:04:59 UTC 2021
Hi,
I noticed this patch got merged into mainline and looking through the HFS+ changes, I noticed something that struck me as odd. I am not familiar with this patch set so perhaps it is the intention but I wanted to ask you because it just seems strange thing to do.
So you are adding a new argument of "struct user_namespace *mnt_userns" to lots of functions but then inside the functions when they call another function you often make that use "&init_user_ns" instead of the passed in "mnt_userns" which kind of defeats the point of having the new "mnt_userns" argument altogether, doesn't it?
Example after this chunk:
diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index 642e067d8fe8..7a937de9b2ad 100644
--- a/fs/hfsplus/inode.c
+++ b/fs/hfsplus/inode.c
@@ -241,7 +241,8 @@ static int hfsplus_file_release(struct inode *inode, struct file *file)
return 0;
}
-static int hfsplus_setattr(struct dentry *dentry, struct iattr *attr)
+static int hfsplus_setattr(struct user_namespace *mnt_userns,
+ struct dentry *dentry, struct iattr *attr)
{
struct inode *inode = d_inode(dentry);
int error;
The code now looks like this:
static int hfsplus_setattr(struct user_namespace *mnt_userns,
struct dentry *dentry, struct iattr *attr)
{
struct inode *inode = d_inode(dentry);
int error;
error = setattr_prepare(&init_user_ns, dentry, attr);
if (error)
return error;
[...]
setattr_copy(&init_user_ns, inode, attr);
mark_inode_dirty(inode);
return 0;
}
Shouldn't that be using mnt_userns instead of &init_user_ns both for the setattr_prepare() and setattr_copy() calls?
Please note this is just one example - it seems the kernel is now littered with such examples in current mainline and I don't mean just HFS+ - this is now all over the place...
Best regards,
Anton
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
More information about the Linux-security-module-archive
mailing list