Joel Becker <jlbec@xxxxxxxxxxxx> writes: > On Tue, Nov 20, 2012 at 04:43:37AM -0800, Eric W. Biederman wrote: >> --- a/fs/ocfs2/file.c >> +++ b/fs/ocfs2/file.c >> @@ -1116,7 +1116,8 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr *attr) >> (unsigned long long)OCFS2_I(inode)->ip_blkno, >> dentry->d_name.len, dentry->d_name.name, >> attr->ia_valid, attr->ia_mode, >> - attr->ia_uid, attr->ia_gid); >> + from_kuid(&init_user_ns, attr->ia_uid), >> + from_kgid(&init_user_ns, attr->ia_gid)); > > Dear Eric, > I have a similar question about init_user_ns to Dave. As far as > I can tell, using init_user_ns here means we'll never get translations > based on the current process namespace. It just so happens that > include/linux/user_namespace.h doesn't allow new namespaces yet, but I > can't see why we would propagate that knowledge elsewhere. > > Is there some magic about when init_user_ns should be used > regardless? Trace statements are fancy print statements, and the tracing infrastructure is not setup to deal with anyone other than the one-true-root using it. Trace is like printk in that way. So for print statements I always convert the value into the initial user namespace which every value can be converted to without loss, and is the same value that we have always been printing. If at some point the tracing people figure out how deal with multiple user namespaces it won't be hard to pass the kuids and kgids into the trace funtions and have the readers of the data perform the conversions. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
