On Tue, May 05, 2009 at 07:44:01AM -0400, Stephen Smalley wrote: > On Mon, 2009-05-04 at 14:30 -0700, Joel Becker wrote: > > Wouldn't testing inode_change_ok() be the right thing here? > > Hits up uid, gid, perms, times. > > I don't think so, as you aren't actually changing the attributes of an > inode but rather are cloning the attributes from the original to the new > one. And I doubt you want the same level of restrictiveness, since in > the reflink(2) case, the process is limited to only preserving the > original attributes (not setting arbitrary values) and only on the same > content/data (not on arbitrary content/data). Ok, I was looking at avoiding re-implementing the UID/GID checks, but I suppose I'll just do them straight up in vfs_reflink(). Joel -- Life's Little Instruction Book #407 "Every once in a while, take the scenic route." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@xxxxxxxxxx Phone: (650) 506-8127 -- 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