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@xxxxxxxxxx
Phone: (650) 506-8127
--
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
