Re: New reflink(2) syscall

[Stephen Smalley <sds@tycho.nsa.gov>]

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