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]

Date:	Thu, 16 Feb 2012 18:10:57 -0500
From:	Phillip Susi <psusi@...ntu.com>
To:	Ted Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] e2image: truncate raw image file to correct size

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/16/2012 05:58 PM, Ted Ts'o wrote:
> 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.

- From what I can see, when sparse == 0, the last write does a seek to move
the file pointer, but doesn't write anything beyond the last hole, so i_size
is not updated.  This resulted in an image file I took of a 20gb fs being 124
MiB too small.  I can only assume that this is to be expected, and is the
reason for passing one byte of zero_buff to write_block instead of not giving
it any bytes to write, and just asking it to do the seek the way the loop does.

> 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.)

Good idea.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPPY0BAAoJEJrBOlT6nu75ZpQH+QH0OGFfY0Tde0SZ3gl1QPeo
pbzYRA6Io6uxOMqLwYlOxfmxoaHByuQQupVDAyNtSLVEdGXvaixTNH/omu4TTYcR
54YARfgnsNlpfiJ8cYEP5jqNUvvIfqjqgBZncFYGiP/1smMh8uz56ThkHJtjaaSV
hEs1R9F6PdF+cplmsQooRAWedIR8f/Nd9KncKaKHOPiUKDr+3kbneBfbYMrqz6U9
ftoKVYNXNIb0+u9KxOFZybYMkiKoDQrMIUDkXCI39Mgkga/+3SelDZ+vl9Ax142e
oEAQfC6RrI86Oh+OjF3YeBQdreyz4ddkEnjFv/EgsfW8PPBw+iYt1NiaXiCUgd4=
=Kz4m
-----END PGP SIGNATURE-----
--
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