[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200804241729.m3OHTnNx016180@agora.fsl.cs.sunysb.edu>
Date: Thu, 24 Apr 2008 13:29:49 -0400
From: Erez Zadok <ezk@...sunysb.edu>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, dave@...ux.vnet.ibm.com,
ezk@...sunysb.edu, mhalcrow@...ibm.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] vfs: add helpers to check r/o bind mounts
In message <20080424142857.GF15214@...IV.linux.org.uk>, Al Viro writes:
> On Thu, Apr 24, 2008 at 04:09:18PM +0200, Miklos Szeredi wrote:
[...]
> FWIW, I'm not all that happy about the way ecryptfs_interpose() is done,
> while we are at it. We get the sucker opened by whoever steps on given
> place in the tree first, with subsequent operations done using the resulting
> struct file. With fallback to r/o open. What happens to somebody who
> tries to open it with enough permissions to do r/w?
Yes, ecryptfs_interpose() calls ecryptfs_init_persistent_file() which calls
dentry_open(O_RDWR). What's the proposed solution for this in the face of
r/o vfsmounts? How could ecryptfs avoid calling this dentry_open in the
first place?
For unionfs, all I need is return -EROFS or the like to trigger a possible
copyup.
Erez.
--
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/
Powered by blists - more mailing lists