linux-kernel - Re: [PATCH 00/22][RFC] Unionfs: Stackable Namespace Unification Filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Sep 2006 19:31:31 -0400
From:	Josef Sipek <jsipek@....cs.sunysb.edu>
To:	Shaya Potter <spotter@...columbia.edu>
Cc:	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, hch@...radead.org, akpm@...l.org,
	viro@....linux.org.uk
Subject: Re: [PATCH 00/22][RFC] Unionfs: Stackable Namespace Unification Filesystem

On Mon, Sep 04, 2006 at 05:43:04PM -0400, Shaya Potter wrote:
> On Mon, 2006-09-04 at 22:33 +0200, Pavel Machek wrote:
> > On Mon 2006-09-04 09:28:26, Shaya Potter wrote:
> > > On Sun, 2006-09-03 at 11:05 +0000, Pavel Machek wrote:
> > > > > - Modifying a Unionfs branch directly, while the union is mounted, is
> > > > >   currently unsupported.  Any such change may cause Unionfs to oops and it
> > > > >   can even result in data loss!
> > > > 
> > > > I'm not sure if that is acceptable. Even root user should be unable to
> > > > oops the kernel using 'normal' actions.
> > > 
> > > As I said in the other case.  imagine ext2/3 on a a san file system
> > > where 2 systems try to make use of it.  Will they not have issues?
> > 
> > They probably will have issues (altrough I'm not sure, perhaps ext2
> > has been debugged enough), but they'll fix them (as opposed to
> > document that oopses are okay).
> 
> I agree that unionfs shouldn't oops, it should handle that situation in
> a more graceful manner,

Agreed. The solution is to make the VFS little friendlier to stackable
filesystems. I'm not sure what the best way of accomplishing that would be.
There are some papers about it [1], but my gut feeling is that they are way
too invasive.

> but once the "backing store" is modified underneath it, all bets are off
> for either unionfs or ext2/3 behaving "correctly"
 
Exactly.
 
> where does one draw the line?  I agree that stackable file systems make
> this a more pressing issue, as the "backing store" can be visible within
> the file system namespace as a regular file system that people are
> generally accustomed to interacting with.

The unionfs (as well as any other stackable filesystem) case can be fixed up
by making the VFS aware of the stack - for example, by having some kind of
stackable filesystem callbacks.

Josef 'Jeff' Sipek.

[1] http://www.isi.edu/people/johnh/PAPERS/Heidemann95e.html

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/