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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
