Re: New reflink(2) syscall

[Joel Becker <Joel.Becker@oracle.com>]

[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.

JOel

-- 

"Sometimes I think the surest sign intelligent
 life exists elsewhere in the universe is that
 none of it has tried to contact us."
                                -Calvin & Hobbes

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127