Re: [RFC] The reflink(2) system call v2.

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

On Fri, May 08, 2009 at 11:39:53AM +1000, James Morris wrote:
> On Thu, 7 May 2009, Joel Becker wrote:
> 
> 
> > @@ -1402,6 +1419,8 @@ struct security_operations {
> >  			  struct dentry *new_dentry);
> >  	int (*path_rename) (struct path *old_dir, struct dentry *old_dentry,
> >  			    struct path *new_dir, struct dentry *new_dentry);
> > +	int (*path_reflink) (struct dentry *old_dentry, struct path *new_dir,
> > +			     struct dentry *new_dentry);
> >  #endif
> >  
> 
> The TOMOYO folk don't need a path hook, so it would be unused, and should 
> not be added unless someone responsible for an in-tree LSM establishes a 
> case for it.

	Oh, I misread what they said:

> TOMOYO wants to prevent reflink(".htpasswd", "readme.html").
> But security_path_mknod() can't know the source file's name.
> Therefore, TOMOYO wants security_path_link() rather than security_path_mknod().
> So far I don't feel TOMOYO needs to introduce security_path_reflink() > because
> modifications after reflink() will be checked by other LSM hooks.

	So I should change the path_reflink() call to path_link() in
reflinkat(2)?

> > +int security_inode_reflink(struct dentry *old_dentry, struct inode *dir,
> > +			   struct dentry *new_dentry);
> 
> We don't need the new_dentry argument (this is correct in the low-level 
> hook, and doesn't compile with CONFIG_SECURITY=y).

	Eek, missed that.

Joel

-- 

"The cynics are right nine times out of ten."  
        - H. L. Mencken

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