[lkml]   [2007]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Tuesday 06 February 2007 01:47, Christoph Hellwig wrote:
> On Mon, Feb 05, 2007 at 07:20:35PM -0800, Andreas Gruenbacher wrote:
> > It's actually not hard to "fix", and nfsd would look a little less weird.
> > But what would this add, what do pathnames mean in the context of nfsd,
> > and would nfsd actually become less weird?
> It's not actually a pathname we care about, but a vfsmount + dentry
> combo. That one means as much in nfsd as elsewhere. We want nfsd
> to obey r/o or noatime mount flags if /export/foo is exported with them
> but /foo not.

This assumes that you can discover from the file handle which export it
belongs to. And right, this can be done using the fsid export option. Okay,
I'm now convinced that passing the vfsmounts from the svc_export to the vfs_
helpers is good at least for *something*. I'll update the patches.

> > 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.
> This doesn't matter. hardlinks are per definition on the same vfsmount.

Hardlinks are per definition on the same filesystem. This doesn't mean that
you can't have two filehandles for the same file but with different
vfsmounts -- you can have the same file visible in multiple locations, each
with their own vfsmount.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-07 11:01    [W:0.227 / U:0.992 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site