linux-ext4 - Re: [PATCH 1/2] e2image: truncate raw image file to correct size

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: <20120216225810.GB26473@thunk.org>
Date:	Thu, 16 Feb 2012 17:58:10 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Phillip Susi <psusi@...ntu.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] e2image: truncate raw image file to correct size

On Thu, Feb 16, 2012 at 04:35:11PM -0500, Phillip Susi wrote:
> At the end of writing the raw image file, output_meta_data_blocks()
> wrote a single zero byte.  Not only does this cause the last block
> of the image file to be non sparse, but this was being skipped if
> there were no leftover sparse bytes from the main loop.  This would
> happen if the source fs happened to have an even multiple of 1MiB
> of free blocks at the end, leaving the sparse image file shorter
> than it should be.

I don't see the bug here.  If there are no leftover sparse bytes,
there's no need to write the last zero byte.  The whole point was to
make sure i_size was set correctly, and if sparse==0, then i_size is
correct.

> Instead of writing a null byte, just truncate() the file instead,
> whether or not there are any leftover sparse bytes.

ftruncate() happens to work today for Linux, but it's not guaranteed
to do anything on all operating systems or even all file systems.  Per
the standards spec:

	If the file previously was smaller than this size, ftruncate()
	shall either increase the size of the file or fail.

Speaking of which, you're not checking the return value from ftruncate
in your patch.  So I'd be happy if you checked ftruncate, and if it
failed, falling back to the

	if (sparse)
		write_block(fd, zero_buf, sparse-1, 1, -1);

code path.  That way, if ftruncate() happens to fail on NFS, or ceph,
or some random file system that chose to meet the standards spec, but
by failing if someone tries to increase the size of the file using
ftruncate.  (Or some other OS; there are other operating systems,
including GNU Hurd and BSD, and I don't know for sure how ftruncate
behaves on all of those other OS's and file systems.)

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html