Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

[Andreas Gruenbacher <agruen@suse.de>]

Hi Trond,

On Tuesday 06 February 2007 00:51, Trond Myklebust wrote:
> > But there is no way to tell different hardlinks to the same inode in the
> > same directory from each other (both the file and directory inode are the
> > same), and depending on the export options, we may or may not be able to
> > distinguish different hardlinks across directories.
>
> Who cares? There is no way to export a partial directory, and in any
> case the subtree_check crap is borken beyond repair (see cross-directory
> renames which lead to actual changes to the filehandle - broken, broken,
> broken!!!!).

I do agree that the directory inode number would better not be part of the 
filehandle. In this thread I'm trying to argue why trying to compute 
pathnames based on nfs file handles makes no sense though, and that the sane 
thing is not to even try.

> > If the nohide or crossmnt export options are used, we might run into
> > similar aliasing issues with mounts (I'm not sure about this).
>
> Wrong. Those create new export points since you are crossing into a
> different filesystem.

I'm glad to be proven wrong here. Pathnames for nfs remain meaningless even 
without mount point aliasing, though.

> > So we could compute pathnames, but they wouldn't be very meaningful.
> > Instead of going that way, it seems more reasonable to not do pathname
> > based access control for the kernel kernel nfsd at all. Passing NULL as
> > the vfsmounts does that. With a properly configured nfsd, the areas that
> > remote users could access would still be well confined.
>
> Huh? Even if you don't pass in a vfsmount, you _still_ need to pass in a
> super_block. Inodes are only unique per filesystem.

No worries, the super_block is not hanging off struct vfsmount, it's hanging 
off struct dentry.

Thanks,
Andreas