LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Christoph Hellwig <hch@infradead.org>, Tony Jones <tonyj@suse.de>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	chrisw@sous-sol.org, linux-security-module@vger.kernel.org,
	viro@zeniv.linux.org.uk
Subject: Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
Date: Wed, 7 Feb 2007 01:25:33 -0800	[thread overview]
Message-ID: <200702070125.34162.agruen@suse.de> (raw)
In-Reply-To: <1170751912.6242.30.camel@lade.trondhjem.org>

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

  parent reply	other threads:[~2007-02-07  9:25 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-05 18:22 Tony Jones
2007-02-05 18:22 ` [RFC 1/28] Pass struct vfsmount to the inode_create LSM hook Tony Jones
2007-02-05 18:22 ` [RFC 2/28] Remove redundant check from proc_setattr() Tony Jones
2007-02-05 19:16   ` Chris Wright
2007-02-05 18:22 ` [RFC 3/28] Pass struct file down to remove_suid and children Tony Jones
2007-02-05 18:22 ` [RFC 4/28] Add a vfsmount parameter to notify_change() Tony Jones
2007-02-05 18:23 ` [RFC 5/28] Pass struct vfsmount to the inode_setattr LSM hook Tony Jones
2007-02-05 18:23 ` [RFC 6/28] Add struct vfsmount parameter to vfs_mkdir() Tony Jones
2007-02-05 18:23 ` [RFC 7/28] Pass struct vfsmount to the inode_mkdir LSM hook Tony Jones
2007-02-05 18:23 ` [RFC 8/28] Add a struct vfsmount parameter to vfs_mknod() Tony Jones
2007-02-05 18:23 ` [RFC 9/28] Pass struct vfsmount to the inode_mknod LSM hook Tony Jones
2007-02-05 18:23 ` [RFC 10/28] Add a struct vfsmount parameter to vfs_symlink() Tony Jones
2007-02-05 18:23 ` [RFC 11/28] Pass struct vfsmount to the inode_symlink LSM hook Tony Jones
2007-02-05 18:24 ` [RFC 12/28] Pass struct vfsmount to the inode_readlink " Tony Jones
2007-02-05 18:24 ` [RFC 13/28] Add struct vfsmount parameters to vfs_link() Tony Jones
2007-02-05 18:24 ` [RFC 14/28] Pass struct vfsmount to the inode_link LSM hook Tony Jones
2007-02-05 18:24 ` [RFC 15/28] Add a struct vfsmount parameter to vfs_rmdir() Tony Jones
2007-02-05 18:24 ` [RFC 16/28] Pass struct vfsmount to the inode_rmdir LSM hook Tony Jones
2007-02-05 18:24 ` [RFC 17/28] Add a struct vfsmount parameter to vfs_unlink() Tony Jones
2007-02-05 18:25 ` [RFC 18/28] Pass struct vfsmount to the inode_unlink LSM hook Tony Jones
2007-02-05 18:25 ` [RFC 19/28] Add struct vfsmount parameters to vfs_rename() Tony Jones
2007-02-05 18:25 ` [RFC 20/28] Pass struct vfsmount to the inode_rename LSM hook Tony Jones
2007-02-05 18:25 ` [RFC 21/28] Add a struct vfsmount parameter to vfs_setxattr() Tony Jones
2007-02-05 18:25 ` [RFC 22/28] Pass struct vfsmount to the inode_setxattr LSM hook Tony Jones
2007-02-05 18:25 ` [RFC 23/28] Add a struct vfsmount parameter to vfs_getxattr() Tony Jones
2007-02-05 18:25 ` [RFC 24/28] Pass struct vfsmount to the inode_getxattr LSM hook Tony Jones
2007-02-05 18:26 ` [RFC 25/28] Add a struct vfsmount parameter to vfs_listxattr() Tony Jones
2007-02-05 18:26 ` [RFC 26/28] Pass struct vfsmount to the inode_listxattr LSM hook Tony Jones
2007-02-05 18:26 ` [RFC 27/28] Add a struct vfsmount parameter to vfs_removexattr() Tony Jones
2007-02-05 18:26 ` [RFC 28/28] Pass struct vfsmount to the inode_removexattr LSM hook Tony Jones
2007-02-05 18:44 ` [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks Christoph Hellwig
2007-02-05 18:58   ` Trond Myklebust
2007-02-05 19:02     ` Christoph Hellwig
2007-02-06  3:20       ` Andreas Gruenbacher
2007-02-06  8:51         ` Trond Myklebust
2007-02-06  9:48           ` Christoph Hellwig
2007-02-06 10:31             ` Neil Brown
2007-02-07  9:25           ` Andreas Gruenbacher [this message]
2007-02-06  9:47         ` Christoph Hellwig
2007-02-06 10:26           ` Neil Brown
2007-02-06 10:37             ` Christoph Hellwig
2007-02-12 18:32               ` J. Bruce Fields
2007-02-07  9:58           ` Andreas Gruenbacher
2007-02-07 12:11             ` Christoph Hellwig
2007-02-05 19:15     ` Chris Wright
2007-02-06  0:44   ` Andreas Gruenbacher
2007-02-06  2:13   ` Andreas Gruenbacher
2007-02-06  9:52     ` Christoph Hellwig
2007-02-07  9:04       ` Andreas Gruenbacher
2007-02-06 12:55     ` Stephen Smalley
2007-02-07  8:55       ` Andreas Gruenbacher
2007-02-07 15:43         ` Chris Wright
2007-02-07 16:06           ` Stephen Smalley
2007-02-07 16:25           ` Jeff Mahoney
2007-02-07 19:55             ` Andreas Gruenbacher
2007-02-05 19:26 ` Casey Schaufler
2007-02-05 19:39   ` Arjan van de Ven
2007-02-05 19:50   ` Chris Wright
2007-02-05 20:23     ` Casey Schaufler
2007-02-06  2:30     ` Andreas Gruenbacher
2007-02-06 14:20     ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200702070125.34162.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=chrisw@sous-sol.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tonyj@suse.de \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).