On Mon, 2009-05-04 at 11:08 -0700, Joel Becker wrote: > [Re-adding linux-fsdevel] > > On Mon, May 04, 2009 at 01:37:49PM -0400, Stephen Smalley wrote: > > On Mon, 2009-05-04 at 09:35 -0700, Joel Becker wrote: > > > On Mon, May 04, 2009 at 09:16:56AM -0400, Stephen Smalley wrote: > > > > BTW, the DAC permission checking here also needs some thought, and > > > > wouldn't be handled by the LSM hook. Should reflink(2) require DAC read > > > > permission to the file, like a file copy would? And if the owner of the > > > > original differs from the fsuid of the current process, should > > > > reflink(2) require CAP_CHOWN in order to set the ownership of the copy > > > > to the original's owner? > > > > > > I'm thinking it should require read, yes. That's part of what > > > I'm asking. Regarding CAP_CHOWN - I don't want to limit the call to > > > root-only. Are you saying something like "If you have CAP_CHOWN, you > > > can reflink() the sucker and keep the original ownership, otherwise > > > sorry, it's gotta be owned by the current process"? > > > > Is reflink() supposed to be more like link(2) or more like an in-kernel > > optimized file copy? > > More like link(2). > > > And what is the real usage scenario? Are users likely to need/want to > > be able to reflink() to files that they do not own? If so, will they be > > more likely to want to own the new copies or preserve the original > > ownership? > > The real usage scenarios are varied. The idea came out of inode > snapshots. And for that, you really want to preserve everything. But > when we came up with the reflink(2) interface as a more generic way to > invoke it, we came up with a lot of fun uses. > The other mail had a good point - if you can allow someone the > ability to reflink() a file but not read or write it, you might not even > need read permission. I'm thinking of a snapshotter that can make > snapshots with only the permissions to create in the snapshot directory. > That's neat. > > > If you want to support multiple attribute assignment behaviors (e.g. > > sometimes preservation, sometimes inherit from the process), then you > > should make that explicit in the interface, e.g. preservation flags for > > the different attributes, and fail the operation if unable to honor the > > request. > > 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. -- 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
