linux-kernel - Union mounts and file locks (was Re: [PATCH 14/39] union-mount: Union mounts documentation)

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

Message-ID: <20100817210610.GF5556@shell>
Date:	Tue, 17 Aug 2010 17:06:10 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	"J. R. Okajima" <hooanon05@...oo.co.jp>,
	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	Neil Brown <neilb@...e.de>,
	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: Union mounts and file locks (was Re: [PATCH 14/39] union-mount: Union mounts documentation)

On Wed, Aug 11, 2010 at 10:51:52AM +0900, J. R. Okajima wrote:
> 
> Also here is my concern about UnionMount. All these issues have been
> reported before.
> - for users, the inode number may change silently. eg. copy-up.
> - link(2) may break by copy-up.
> - read(2) may get an obsoleted filedata (fstat(2) too).
> - fcntl(F_SETLK) may be broken by copy-up.
> - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after
>   open(O_RDWR).

You forgot fchmod()/fchown()/fsetxattr()/utimensat() failing on
O_RDONLY file descriptors. :)

These are all known limitations of union mounts, with the exception of
fcntl(F_SETLK).  Several people asked about this at the LSF workshop
and I said I'd look into it.

The short version is that in-kernel file copyup will affect locks the
same way as a concurrent rename() over the target.  If an application
opens a file read-only and gets a lock on it, and another application
(or the same one) opens the file read-write and takes a lock on it,
the first lock will be on the read-only file on the lower layer, and
the second lock will be on the file copied up to the top layer.  This
isn't what you want, obviously.

Union mounts behaves this way with locks for the same reason as
fchmod(), etc. on O_RDONLY file descriptors fails.  In-kernel copyup
only happens before a file descriptor is open.  Once it is open, it is
very difficult to switch the open file with the newly copied up file
("very difficult" meaning "Al Viro refuses to even discuss it").
fcntl() is called on an open file descriptor, so the decision to
copyup or not has already been made, based on the mode given to
open().

However, fcntl(F_SETLK) on a file opened read-write will behave
exactly as expected.  The question is how many applications call
fcntl(F_SETLK) on a read-only file descriptor as the first lock
operation on a file?  Of those applications, how many could easily be
rewritten to open that file descriptor with write permissions?

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