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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Oct 2009 21:43:39 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	hooanon05@...oo.co.jp
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>,
	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 Sat, Oct 03, 2009 at 12:30:42AM +0900, hooanon05@...oo.co.jp wrote:
> 
> Hi,
> 
> Valerie Aurora:
> > Writable overlays (formerly union mounts)
> > =========================================
> > 
> > In this document:
> >  - Overview of writable overlays
> >  - Terminology
> >  - VFS implementation
> 	:::
> 
> While I don't remember exactly when I first read the source files of
> UnionMount, I think it is promising. And I have written to Val and Jan
> some of my comments or reviews about UnionMount.
> Recently I noticed another issue about stat(2) and mountpoint(1). The
> latter is a part of 'initscripts' package.
> 
> For example,
> - you have a union-ed directory, /u = /rw + /ro
> - /ro/usr dir exists
> - /rw/usr dir does NOT exist
> - of course, /u/usr exists
> 
> As far as I know, UnionMount is expected to handle /u/usr directory
> as if it exists under /u dir.
> (I may be wrong since it totally depends upon the design of UnionMount)
> 
> In this case, stat(2) for /u and /u/usr will return different st_dev
> from each other. eg. stat(/u/usr) returns the st_dev value of /ro,
> stat(/u) returns the one for /rw.
> 
> This behaviour may make /bin/mountpoint confused, particulary in the
> chroot/switch_root-ed environment.
> /bin/mountpoint issues stat(2) for the specified dir and its parent, and
> compares their st_dev. If they differ from each other, the utility
> handles the specified dir as a "mountpoint". I am afraid it will make
> some init-scripts crazy because /u/usr is NOT a mountpoint actually.

In writable overlays, every directory will be copied up to the top
writable overlay, so /u and /u/usr will both have the same st_dev.
The copy up happens on lookup, so a stat() will trigger this copy up.
A directory and a regular file in it will have different st_dev's,
though.  Can you foresee any problems with that?

Thanks again,

-VAL

> One possible solution will be setting a hook to vfs_stat(), which
> handles the vfsmount set UNION flag differently and returns the pseudo
> st_dev for the entires in UnionMount. But it may lead to the duplicated
> inode number situation which may make applications crazy.
> For instance,
> - /ro/fileA is hardlinked to /ro/fileB.
> - the inode number of them is i100.
> - /rw/fileC is handlinked to /rw/fileD.
> - the inode number of them is i100 too.
> 
> Since /ro and /rw are different, the same inode number is not a
> problem natively. But if UnionMount takes an approach above, they all
> have the same st_dev value. And I am afraid some applications may
> handle them as a single hardlink unexpectedly.
> 
> So UnionMount should maintain its inode numbers by itself?
> No, it goes to the filesystem-type implementation. It should not be the
> way of UnionMount.
> Are there any ideas to solve this problem?
> 
> 
> J. R. Okajima
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/