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:	Wed, 18 Aug 2010 02:15:20 +0200
From:	Luca Barbieri <luca@...a-barbieri.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Valerie Aurora <vaurora@...hat.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Miklos Szeredi <miklos@...redi.hu>,
	Jan Blunck <jblunck@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 14/39] union-mount: Union mounts documentation

>> I personally like the block layer solution better and would be
>> happiest if all unionfs and aufs users switched to it and no one
>> needed union mounts. :)

I think that the safety of personal data and the ability to make
changes to the layers independently are very important features that
justify union mounts.

If you do block-level COW and then lose the lower filesystem layer
(e.g. lose the LiveCD or lose network access to the NFS master), then
you have no guarantee of being able to access the data you added (e.g.
your /home) since you'll only have a corrupted "filesystem piece" that
fsck may or may not be able to fix.

Also, you can't modify the lower layer at all (without rebuilding the
upper layer from scratch), while with an union mount minor changes can
be done with no issues (e.g. replacing the LiveCD with a new minor
update, or applying a security update to the NFS master), and major
ones can be done with some care.

Hence, in any case where the layers are even slightly separated, or
where you need to modify them independently, or extract the changes,
union mounts/unionfs are much better, and often actually the only
viable solution.

This includes the LiveCD case, the NFS mount case and some use cases
with virtual machines.

This would be the case even more strongly if additional features like
online modification of lower layers, or path resolution to the most
recent file instead of the one in the highest layer, were added.

Of course, this is why people currently use unionfs or aufs, and a
VFS-based solution seems just better, since it is going to be more
efficient and guaranteed to be relatively bug-free once it satisfies
the high quality requirements for inclusion in the core kernel.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ