[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080424201630.GC18686@localhost.austin.ibm.com>
Date: Thu, 24 Apr 2008 15:16:30 -0500
From: Michael Halcrow <mhalcrow@...ibm.com>
To: Erez Zadok <ezk@...sunysb.edu>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, dave@...ux.vnet.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
On Thu, Apr 24, 2008 at 03:40:03PM -0400, Erez Zadok wrote:
> Ah, I see. Yes: ecryptfs_init_persistent_file does have this odd
> "try to open readwrite and if that failed, try readonly" code there.
> I can't really say why it's done that way: Mike? Maybe it was a
> workaround to not having the right permissions to open that
> persistent file?
The notion was that of "best effort," and it is sloppy.
I think the right way to do it will be to allow up to two persistent
files. If the user with read-only perms opens, then open the
persistent file RO. Then a user with write-only (but not read) perms
opens; open another persistent file WO. Allow subsequent reads or
writes by the various users to go through whichever persistent file
has the right access. Then a user with RW access opens the file; close
both the RO file and the WO file and open a new file RW. All the
while, make sure that ecryptfs_open() performs all the requisite perm
checks.
If this sounds reasonable, I will get working on a patch to do this.
Mike
--
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