linux-kernel - Re: [PATCH 17/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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <31248.1272938052@localhost>
Date:	Mon, 03 May 2010 21:54:12 -0400
From:	Valdis.Kletnieks@...edu
To:	Valerie Aurora <vaurora@...hat.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH 17/39] union-mount: Union mounts documentation

On Mon, 03 May 2010 16:12:16 PDT, Valerie Aurora said:

> +File copyup
> +-----------
> +
> +Any system call that alters the data or metadata of a file on the
> +bottom layer, or creates or changes a hard link to it will trigger a
> +copyup of the target file from the lower layer to the topmost layer
> +
> + - open(O_WRITE | O_RDWR | O_APPEND | O_DIRECT)
> + - truncate()/open(O_TRUNC)
> + - link()
> + - rename()
> + - chmod()
> + - chown()/lchown()
> + - utimes()
> + - setxattr()/lsetxattr()

I spent some time looking at patch 27 trying to figure it out for myself,
but my lack of splice()-fu doomed me. :)

A few quick questions:

1) For calls like chmod() that only touch the metadata, does it still
trigger a copyup of the data, or just the affected metadata?

2) Is the copyup of data synchronous or async done in the background?
The comments in union_copyup_len() about "We raced with someone else"
imply this is synchronous - if so. probably a note should be made that
an open() may take a little while under some conditions.  There's a *lot* of
code out there that assumes that open() calls are *really* cheap.

I wonder how many programs don't correctly deal with an ENOSPC on open() of
an already existing file.

(The answers probably don't matter unless somebody ends up invoking a
copyup of a gigabyte file, which of course implies one of my users will end up
doing exactly that. :)

Content of type "application/pgp-signature" skipped