linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org,
	viro@ZenIV.linux.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [patch 04/14] gfs2: dont call permission()
Date: Fri, 23 May 2008 10:12:06 +0100	[thread overview]
Message-ID: <1211533926.3635.552.camel@quoit> (raw)
In-Reply-To: <20080521171546.697638614@szeredi.hu>

Hi,

On Wed, 2008-05-21 at 19:15 +0200, Miklos Szeredi wrote:
> plain text document attachment (gfs2_permission_fix.patch)
> From: Miklos Szeredi <mszeredi@suse.cz>
> 
> GFS2 calls permission() to verify permissions after locks on the files
> have been taken.
> 
> For this it's sufficient to call gfs2_permission() instead.  This
> results in the following changes:
> 
>   - IS_RDONLY() check is not performed
>   - IS_IMMUTABLE() check is not performed
>   - devcgroup_inode_permission() is not called
>   - security_inode_permission() is not called
> 
> IS_RDONLY() should be unnecessary anyway, as the per-mount read-only
> flag should provide protection against read-only remounts during
> operations.  do_gfs2_set_flags() has been fixed to perform
> mnt_want_write()/mnt_drop_write() to protect against remounting
> read-only.
> 
> IS_IMMUTABLE has beed added to gfs2_do_permission()
> 
That looks ok, but I wonder do we really need gfs2_do_permission() and
gfs2_permission when the only difference seems to be one argument?

> Repeating the security checks seems to be pointless, as they don't
> normally change, and if they do, it's independent of the filesystem
> state.
> 
I hope eventually we can fix this by allowing GFS2 to do its own
lookups, via a suitable VFS library function. I understand that is the
preferred option to replace "open intents" (which we don't currently use
anyway) in the longer term.

> I also suspect the conditional locking in gfs2_do_permission() could
> be cleaned up, due to the removal of the implicit recursion.
> 
In order to be sure we'd have to check that there are no NFS code paths
left which can reach this code. That has usually been the reason for
conditional locking.

In general the patch looks ok to me, and since it doesn't appear to
depend on anything else, I can drop it in my GFS2 git tree if that would
be helpful at this stage,

Steve.



  reply	other threads:[~2008-05-23  9:15 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-21 17:14 [patch 00/14] vfs: permission API cleanup Miklos Szeredi
2008-05-21 17:14 ` [patch 01/14] vfs: add path_getxattr() Miklos Szeredi
2008-05-21 17:15 ` [patch 02/14] vfs: add path_listxattr() Miklos Szeredi
2008-05-21 17:15 ` [patch 03/14] hppfs: remove hppfs_permission Miklos Szeredi
2008-05-23  9:17   ` Christoph Hellwig
2008-05-21 17:15 ` [patch 04/14] gfs2: dont call permission() Miklos Szeredi
2008-05-23  9:12   ` Steven Whitehouse [this message]
2008-05-23  9:30     ` Miklos Szeredi
2008-05-23  9:32     ` Christoph Hellwig
2008-05-23  9:18   ` Christoph Hellwig
2008-05-23  9:48     ` Miklos Szeredi
2008-05-23 10:00       ` Miklos Szeredi
2008-05-25 19:24         ` Christoph Hellwig
2008-05-23 10:18       ` Steven Whitehouse
2008-05-23 11:01         ` Miklos Szeredi
2008-05-25 19:23       ` Christoph Hellwig
2008-05-21 17:15 ` [patch 05/14] hpfs: " Miklos Szeredi
2008-05-23  9:20   ` Christoph Hellwig
2008-05-21 17:15 ` [patch 06/14] hfsplus: remove hfsplus_permission() Miklos Szeredi
2008-05-21 20:35   ` Roman Zippel
2008-05-22  7:58     ` Miklos Szeredi
2008-05-22 12:02       ` Roman Zippel
2008-05-22 12:17         ` Miklos Szeredi
2008-05-22 12:28           ` Roman Zippel
2008-05-22 12:37             ` Miklos Szeredi
2008-05-23  9:21               ` Christoph Hellwig
2008-05-23 15:18                 ` Roman Zippel
2008-05-23 15:31                   ` Miklos Szeredi
2008-05-23 15:49                     ` Miklos Szeredi
2008-05-23 16:30                       ` Roman Zippel
2008-05-23 18:02                         ` Miklos Szeredi
2008-05-23 18:33                           ` Roman Zippel
2008-05-23 19:05                             ` Miklos Szeredi
2008-05-23 21:52                               ` Roman Zippel
2008-05-24  6:59                                 ` Miklos Szeredi
2008-05-23 15:11               ` Roman Zippel
2008-05-21 17:15 ` [patch 07/14] vfs: pass dentry to permission() Miklos Szeredi
2008-05-21 20:29   ` Al Viro
2008-05-22  7:00     ` Miklos Szeredi
2008-05-22  7:12       ` Miklos Szeredi
2008-05-21 17:15 ` [patch 08/14] vfs: cleanup i_op->permission() Miklos Szeredi
2008-05-21 17:15 ` [patch 09/14] security: dont pass nameidata to security_inode_permission() Miklos Szeredi
2008-05-21 22:52   ` James Morris
2008-05-21 17:15 ` [patch 10/14] vfs: pass flags to dentry_permission() Miklos Szeredi
2008-05-21 17:15 ` [patch 11/14] vfs: move executable checking into ->permission() Miklos Szeredi
2008-05-21 18:16   ` Trond Myklebust
2008-05-21 19:09     ` Miklos Szeredi
2008-05-21 19:26       ` Trond Myklebust
2008-05-21 19:34         ` Miklos Szeredi
2008-05-23  9:26   ` Christoph Hellwig
2008-05-23  9:52     ` Miklos Szeredi
2008-05-21 17:15 ` [patch 12/14] vfs: create path_permission() Miklos Szeredi
2008-05-21 17:15 ` [patch 13/14] vfs: dont use dentry_permission() Miklos Szeredi
2008-05-21 17:15 ` [patch 14/14] vfs: path_permission() clean up flags Miklos Szeredi

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=1211533926.3635.552.camel@quoit \
    --to=swhiteho@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=viro@ZenIV.linux.org.uk \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).