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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200702070158.15997.agruen@suse.de>
Date:	Wed, 7 Feb 2007 01:58:15 -0800
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	Tony Jones <tonyj@...e.de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	linux-security-module@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [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.

Thanks,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/