On Mon, 2009-05-04 at 14:30 -0700, Joel Becker wrote: > On Mon, May 04, 2009 at 02:03:56PM -0700, Joel Becker wrote: > > On Mon, May 04, 2009 at 03:30:46PM -0400, Stephen Smalley wrote: > > > > Yeah, I really don't want to create multiple behaviors. I > > > > wasn't proposing the "behaves differently on CAP_CHOWN," I was trying to > > > > clarify what you were thinking. > > > > > > Given that normally users can't create files with other ownerships, it > > > seemed that we might want to require CAP_CHOWN or some other capability > > > in order to reflink(2) a file that isn't owned by the fsuid of the > > > process. Possibly is_owner_or_cap(), i.e. owner or CAP_FOWNER, would be > > > suitable. > > > > Yeah, the more I think about it the more I agree. It's a simple > > story - you're creating a file with ownership !you, you need > > owner_or_cap. > > 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). -- Stephen Smalley National Security Agency -- 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
