Re: New reflink(2) syscall

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

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