All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: haveblue@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, neilb@suse.de,
	akpm@linux-foundation.org, hch@infradead.org
Subject: Re: r-o bind in nfsd
Date: Fri, 21 Mar 2008 15:54:51 +0000	[thread overview]
Message-ID: <20080321155451.GU10722@ZenIV.linux.org.uk> (raw)
In-Reply-To: <E1Jciie-0001E6-Dx@pomaz-ex.szeredi.hu>

On Fri, Mar 21, 2008 at 03:59:44PM +0100, Miklos Szeredi wrote:
> Why is it that in fs/nfsd/vfs.c only vfs_mknod() and vfs_rename() are
> surrounded by mnt_want_write/mnt_drop_write, and not the other
> operations (vfs_create, vfs_mkdir, vfs_symlink, ...)?
> 
> I noticed this while looking at the AppArmor patches, which need to
> pass the vfsmount down to the security module.  And I'm wondering, why
> can't mnt_want_write() and mnt_drop_write() be done _inside_ vfs_foo()?
> 
> I know there are a few cases, where filesystems call vfs_foo()
> internally, where the vfsmount isn't available, but I think the proper
> solution is just to fix those places, and not recurse back into the
> VFS (which is AFAICS in all those cases totally unnecessary anyway).
> This would make everybody happy, no?

Apparmor can go play with itself.  The proper fix is to lift the LSM nonsense
into callers and leave vfs_...() alone; vfsmounts should *not* be passed
there at all, with the exception of vfs_follow_link() which gets the full
nameidata.

  reply	other threads:[~2008-03-21 15:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-21 14:59 r-o bind in nfsd Miklos Szeredi
2008-03-21 15:54 ` Al Viro [this message]
2008-03-21 16:24   ` Miklos Szeredi
2008-03-21 16:35     ` Al Viro
2008-03-21 16:54       ` Miklos Szeredi
2008-03-21 17:08         ` Miklos Szeredi
2008-03-21 18:11           ` Al Viro
2008-03-21 18:52             ` Miklos Szeredi
2008-03-21 19:49               ` Al Viro
2008-03-21 20:23                 ` Miklos Szeredi
2008-03-22  2:20                   ` Tetsuo Handa
2008-03-21 21:08               ` Dave Hansen
2008-03-21 21:17                 ` Miklos Szeredi
2008-03-25  2:52         ` Neil Brown
2008-03-25 11:45           ` Tetsuo Handa
2008-03-25 22:32             ` NeilBrown
     [not found]               ` <20080325224919.GM10722@ZenIV.linux.org.uk>
2008-03-25 23:29                 ` NeilBrown
2008-03-26 12:04               ` Stephen Smalley
2008-03-26 16:47                 ` Serge E. Hallyn
2008-03-26 21:35                   ` James Morris
2008-03-27  0:29                     ` Serge E. Hallyn

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=20080321155451.GU10722@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=haveblue@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=neilb@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.