Re: [PATCH 01/24] Unionfs: Documentation

[Josef Sipek <jsipek@fsl.cs.sunysb.edu>]

On Mon, Jan 08, 2007 at 05:00:18PM -0600, Michael Halcrow wrote:
> On Mon, Jan 08, 2007 at 03:51:31PM -0500, Erez Zadok wrote:
> > BTW, this is a problem with all stackable file systems, including
> > ecryptfs.  To be fair, our Unionfs users have come up against this
> > problem, usually for the first time they use Unionfs :-).
> 
> I suspect that the only reason why this has not yet surfaced as a
> major issue in eCryptfs is because nobody is bothering to manipulate
> the eCryptfs-encrypted lower files. The only code out there right now
> that can make sense of the files is in the eCryptfs kernel module.
 
Yeah, you got lucky :)
 
> > Detecting such processes may not be easy.  What to do with them,
> > once detected, is also unclear.  We welcome suggestions.
> 
> My first instinct is to say that stacked filesystem should not even
> begin to open the file if it is already opened by something other than
> the stacked filesystem (-EPERM with a message in the syslog about the
> problem).

That seems a rather bit too drastic, no?

> In the case when a stacked filesystem wants to open a file
> that is already opened by something other than the stacked filesystem,
> the stacked filesystem loses. Once the process closes the file, the
> process is hitherto prevented from accessing the file again (via the
> before-mentioned mechanism of hiding the lower namespace).
 
I'd much prefer to somehow link the related pages and invalidate other
"copies" (even after transformations such as encryption). Limiting when
files can be open just sounds nasty.
 
> Unionfs and eCryptfs share almost exactly the same namespace
> issues. Unionfs happens to be impacted by them more than eCryptfs
> because of the differences in how people actually access the files
> under the two filesystems.
 
Yep.
 
> > Jeff, I don't think it's acceptable to OOPS.
> 
> For now, stacked filesystems just need to stay on their toes. There
> are several places where assumptions need to be checked.

I think those places can eliminated by modifying the VFS a bit. Heck, it
might even make the NFS folks' lives easier :)

Josef "Jeff" Sipek.

-- 
Bad pun of the week: The formula 1 control computer suffered from a race
condition
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/