On Thu, Jun 20, 2013 at 09:54:19AM -0400, Dwight Engen wrote: > On Thu, 20 Jun 2013 11:41:33 +1000 > Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > On Wed, Jun 19, 2013 at 01:35:30PM -0700, Eric W. Biederman wrote: > > > > > > I am copying my gmail address so I have a chance of seeing replies > > > from Dave Chiner. So far the only way I have been able to read his > > > replies has been to read mailling lists. Which has not be > > > conductive to having this code discussed properly. Hopefully > > > copying my gmail address will allow us to have a reasonable and > > > timely conversation. > > > > > > > > > Dwight Engen <dwight.engen@xxxxxxxxxx> writes: > > > > > > > Use uint32 from init_user_ns for xfs internal uid/gid > > > > representation in acl, xfs_icdinode. > > > > > > From my review of the code earlier that just isn't safe. It allows > > > all kinds of things to slip through. > > > > Such as? > > Maybe saying "at the vfs boundary" is misleading, I guess I don't see > how this is all that different from what you did in the other > filesystems. Using ext4 as the example the conversions are done between: > struct inode <-> struct ext4_inode > struct posix_acl <-> ext4_acle_entry > > which in xfs is analogous to > struct inode <-> struct xfs_icdinode > struct posix acl <-> struct xfs_acl_entry > > which is where I did the conversions. Yup, that's where they should occur for XFS. > > The kuid_t/kgid_t is actually pushed down this far - it's in the > > struct inode - the code currently uses the on-disk XFS uid/gid, > > not the struct inode's kuid_t/kgid_t. That's easily fixable. > > Yep, I'll go through the code and switch to the inode where possible. Cool. We'll need to be careful, though - there are some code paths that XFS inodes can pass through where the VFS(ip) hasn't been initialised. Let me worry about this during review, though ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
