On Wed, May 06, 2009 at 08:15:08AM +1000, James Morris wrote:
> On Tue, 5 May 2009, Joel Becker wrote:
> > On Mon, May 04, 2009 at 12:59:39PM -0400, Stephen Smalley wrote:
> > > On Tue, 2009-05-05 at 01:35 +1000, James Morris wrote:
> > > > Agreed, perhaps something like:
> > > >
> > > > int security_inode_reflink(struct dentry *dentry, struct inode *dir);
> > >
> > > I'd pass the same arguments as vfs_reflink(), i.e. old_dentry, dir,
> > > new_dentry.
> >
> > I'm about to insert this bit. I agree with
> > security_inode_reflink(old_dentry, dir, new_dentry),
>
> If the files and metadata are initially identical (except for inode #),
> why do we need to see both the old and new dentry?
I'm learning more about the LSM hooks as we go here...
Now, obviously path checkers want the old path and the new path,
but I think we satisfy that with security_path_reflink().
I started by making security_inode_reflink() consistent with
security_inode_link(). There the actual source/dest is the same inode,
yet we have the same argument set. So I have to think that any reason
that holds for security_inode_link() would hold for
security_inode_reflink().
The new_dentry doesn't have an inode here yet, so I would think
you want to look up the security context of the source inode, which is
hanging off of old_dentry. I can't see how you get to it otherwise.
But this is just me speculating based on "reflink looks like
link." If you know you do/don't need fields, I can easily change it.
Joel
--
"The nice thing about egotists is that they don't talk about other
people."
- Lucille S. Harper
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
