linux-kernel - Re: [RFC] Union mounts/writable overlays design

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 1 Oct 2009 13:15:47 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	kevin granade <kevin.granade@...il.com>
Cc:	Jan Blunck <jblunck@...e.de>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	Andy Whitcroft <apw@...onical.com>,
	Scott James Remnant <scott@...onical.com>,
	Sandu Popa Marius <sandupopamarius@...il.com>,
	Jan Rekorajski <baggins@...h.mimuw.edu.pl>,
	"J. R. Okajima" <hooanon05@...oo.co.jp>,
	Arnd Bergmann <arnd@...db.de>,
	Vladimir Dronnikov <dronnikov@...il.com>,
	Felix Fietkau <nbd@...nwrt.org>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Union mounts/writable overlays design

On Thu, Oct 01, 2009 at 10:38:27AM -0500, kevin granade wrote:
> Wow, amazingly thorough writeup, was a very interesting read and I'm looking
> forward to trying this out.
> 
> Examples
> > ========
> >
> > What happens when I...
> >
> > - creat() /newfile -> creates on top layer
> > - unlink() /oldfile -> creates a whiteout on top layer
> > - Edit /existingfile -> copies up to top layer at open(O_WR) time
> > - truncate /existingfile -> copies up to top layer + N bytes if specified
> > - touch()/chmod()/chown()/etc. -> copies up to top layer
> > - mkdir() /newdir -> creates on top layer
> > - rmdir() /olddir -> creates a whiteout on top layer
> > - mkdir() /olddir after above -> creates on top layer w/ opaque flag
> > - readdir() /shareddir -> copies up entries from bottom layer as fallthrus
> > - link() /oldfile /newlink -> copies up /oldfile, creates /newlink on top
> > layer
> > - symlink() /oldfile /symlink -> nothing special
> > - rename() /oldfile /newfile -> copies up /oldfile to /newfile on top layer
> >
> 
> Minor quibble here, rename should also whiteout /oldfile, of course you have
> it explained correctly in the detailed description of rename() below.
> Or am I misunderstanding and the above is what it does now and the detailed
> description is what it will do once implemented properly?

Hi Kevin,

You are correct, it whiteouts the original name.  Thanks for pointing
that out!

> > Non-features
> > ------------
> >
> > Features we do not currently plan to support as part of writable
> > overlays:
> >
> > Online upgrade: E.g., installing software on a file system NFS
> > exported to clients while the clients are still up and running.
> > Allowing the read-only bottom layer to change while the writable
> > overlay file system is mounted invalidates our locking strategy.
> >
> 
> So as long as the RO filesystem is NOT mounted as part of an overlay, you
> could modify it and then re-construct the previous overlay and things will
> work as expected?
> For example could one create a hard drive over CD overlay, then periodically
> (requiring a reboot probably) replace the underlying CD with a new version
> and automagically have new versions of software available?  ( obviously
> there are additional complexities in packaging to make this work, but having
> support in the kernel is the first step. )

This could theoretically work, but the main problem is resolving
differences between files (always the big problem in upgrade).  Say
you have /etc/passwd, you add a new user and write to it on the top
layer, and then the next upgrade adds a new user to the read-only
version.  You're not going to see the new user.

> One last thing, I don't see this in either the "features" or the
> "non-features".  Will there be a way to "revert" a file to the RO version
> once it has been copied up, either by just removing the overlay entry or by
> somehow forcing the open of the underlying file when it has an overlay?  Now
> that I think of it, one could just mount the underlying filesystem elsewhere
> and copy the file, but I'd still be interested to know if there is any
> desire to provide the more "direct" operation.

I think that people are calling this "punch-through."  I don't see a
problem with it, other than slightly more kernel support.

-VAL
--
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/