* [Qemu-devel] remark about http://www.freeoszoo.org @ 2004-10-02 13:16 albi 2004-10-03 17:47 ` Karl Magdsick 0 siblings, 1 reply; 7+ messages in thread From: albi @ 2004-10-02 13:16 UTC (permalink / raw) To: qemu-devel hi, First of all, kudos for developing QEMU! it's cool to play with! :) I noticed an error at the downloads, when i downloaded reactos-0.2.3.tar.bz2 i found out it's really a tar.gz file and not a tar.bz2, can you change that ? thnx cya, albi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] remark about http://www.freeoszoo.org 2004-10-02 13:16 [Qemu-devel] remark about http://www.freeoszoo.org albi @ 2004-10-03 17:47 ` Karl Magdsick 2004-10-03 19:21 ` Lennert Buytenhek 2004-10-04 4:09 ` Brad Campbell 0 siblings, 2 replies; 7+ messages in thread From: Karl Magdsick @ 2004-10-03 17:47 UTC (permalink / raw) To: qemu-devel As a note to anyone planning on uploading QEMU disk images to Free OS Zoo, Free OS Zoo's suggested way of creating disk images does not (in the general case) blank out the unused space in the disk image. As a result, the image will likely contain parts of deleted files from the host OS. This will reduce compressability of the disk images and may cause the disk images to contian sensitive information, such as passwords and credit card numbers. This isn't a problem unless you think you might possibly give the disk image to someone else in the future. To prevent this, in the dd command, use if=/dev/zero and change the count to be the suggested seek value. Do not specify a seek value. This will cause dd to take longer to create a disk image, but it will zero out the contents of the file, rather than asking the OS to create a file from whatever garbage is left on disk. As much as I like your passwords, credit card numbers, and assorted smutt, I'd rather not download them from Free OS Zoo. -Karl On Sat, 2 Oct 2004 15:16:21 +0200, albi <albi@scii.nl> wrote: > > hi, > > First of all, kudos for developing QEMU! it's cool to play with! :) > > I noticed an error at the downloads, when i downloaded reactos-0.2.3.tar.bz2 > i found out it's really a tar.gz file and not a tar.bz2, can you change that > ? thnx > > cya, > albi > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] remark about http://www.freeoszoo.org 2004-10-03 17:47 ` Karl Magdsick @ 2004-10-03 19:21 ` Lennert Buytenhek 2004-10-04 6:50 ` Karl Magdsick 2004-10-04 4:09 ` Brad Campbell 1 sibling, 1 reply; 7+ messages in thread From: Lennert Buytenhek @ 2004-10-03 19:21 UTC (permalink / raw) To: Karl Magdsick, qemu-devel On Sun, Oct 03, 2004 at 01:47:00PM -0400, Karl Magdsick wrote: > To prevent this, in the dd command, use if=/dev/zero and change the > count to be the suggested seek value. Do not specify a seek value. > This will cause dd to take longer to create a disk image, but it will > zero out the contents of the file, rather than asking the OS to create > a file from whatever garbage is left on disk. You think that "dd if=/dev/null of=blah bs=1024k count=1 seek=1024" creates a file that can have anything else than just zeroes in it, hm? Just try it. And then please apologise to the freeoszee people. --L ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] remark about http://www.freeoszoo.org 2004-10-03 19:21 ` Lennert Buytenhek @ 2004-10-04 6:50 ` Karl Magdsick 2004-10-04 11:29 ` Lennert Buytenhek 0 siblings, 1 reply; 7+ messages in thread From: Karl Magdsick @ 2004-10-04 6:50 UTC (permalink / raw) To: Lennert Buytenhek; +Cc: qemu-devel Free OS Zoo suggests using dd with the seek= option in the _specific_ case of Linux, which appears to be safe. My comment was explicitly a note of caution in the _general_ case. I did not intend to slander the suggestions posted on the Free OS Zoo page. My comments were meant merely as a word of caution about over-generalizing the suggestions of the Free OS Zoo people. Perhaps I should have been more clear about the "in the general case" part of my statement. I meant "general" in the sense of making as few extra assumptions as possible, not in the sense of "common". Unless I had specific knowledge about sparse file support on my filesystem and the behavior of fseek, lseek, llseek, etc. seeking past the end of a file that cannot become sparse on my system, I would not risk personal information on assumptions about the behavior of my system. Documentation of this behavior is spotty at best. (Solaris and Linux manpages, as well as the latest edition of Advanced Programming in the UNIX Environment, implicitly assume that sparse files are available across the board.) In the specific case where you are using a filesystem that supports sparse files (ext2, ext3, ufs, ffs, ntfs, etc.), seeking past the end of the file is well documented and will create a sparse file, and everything will be dandy. HFS+ does not support sparse files, but OS X zeroes out blocks as the seeks force their allocation on HFS+ partitons. The latest Debian-testing for x86 will cause seeks past the end of files on VFAT filesystems to fail, but this is not evident from the documentation. Therefore, for 99% of QEMU users, the suggested method is probably safe. I hereby apologise to anyone that feels I have over-stated the risks involved in using dd to seek past the end of a file on arbitrary filesystems and arbitrary OSes. In the specific cases of ext2/ext3 on Linux, NTFS on WinXP (cygwin or CoLinux), and HFS+/UFS on OS X, dd will most likely behave correctly with the suggested inputs. (I have no personal experience with dd on WinXP.) In the case of vfat filesystems on Linux, the suggested method will fail in a safe manner, leaking no information. Sorry for any confusion, -Karl On Sun, 3 Oct 2004 21:21:54 +0200, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Sun, Oct 03, 2004 at 01:47:00PM -0400, Karl Magdsick wrote: > > > To prevent this, in the dd command, use if=/dev/zero and change the > > count to be the suggested seek value. Do not specify a seek value. > > This will cause dd to take longer to create a disk image, but it will > > zero out the contents of the file, rather than asking the OS to create > > a file from whatever garbage is left on disk. > > You think that "dd if=/dev/null of=blah bs=1024k count=1 seek=1024" > creates a file that can have anything else than just zeroes in it, > hm? > > Just try it. And then please apologise to the freeoszee people. > > > --L ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] remark about http://www.freeoszoo.org 2004-10-04 6:50 ` Karl Magdsick @ 2004-10-04 11:29 ` Lennert Buytenhek 2004-10-04 11:43 ` Paul Brook 0 siblings, 1 reply; 7+ messages in thread From: Lennert Buytenhek @ 2004-10-04 11:29 UTC (permalink / raw) To: Karl Magdsick; +Cc: qemu-devel On Mon, Oct 04, 2004 at 02:50:31AM -0400, Karl Magdsick wrote: > Free OS Zoo suggests using dd with the seek= option in the _specific_ > case of Linux, which appears to be safe. My comment was explicitly a > note of caution in the _general_ case. Yep. As well as: "[...] the image will likely contain parts of deleted files from the host OS." Just curious, do you have an example of any such system where this would be the case? I don't know of any system that doesn't support sparse files and doesn't pad out the file with zeroes if you truncate(2) it to be bigger. cheers, Lennert ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] remark about http://www.freeoszoo.org 2004-10-04 11:29 ` Lennert Buytenhek @ 2004-10-04 11:43 ` Paul Brook 0 siblings, 0 replies; 7+ messages in thread From: Paul Brook @ 2004-10-04 11:43 UTC (permalink / raw) To: qemu-devel On Monday 04 October 2004 12:29, Lennert Buytenhek wrote: > On Mon, Oct 04, 2004 at 02:50:31AM -0400, Karl Magdsick wrote: > > Free OS Zoo suggests using dd with the seek= option in the _specific_ > > case of Linux, which appears to be safe. My comment was explicitly a > > note of caution in the _general_ case. > > Yep. As well as: > > "[...] the image will likely contain parts of deleted files from > the host OS." > > Just curious, do you have an example of any such system where this > would be the case? I don't know of any system that doesn't support > sparse files and doesn't pad out the file with zeroes if you > truncate(2) it to be bigger. I'm fairly sure any half-sane OS will zero the "sparse" bits of a file on allocation. IIRC even Windows NT does zero the sparse bits of a file. Failure to do so would be a rather large security hole, effectively allowing unprivileged users to read privileged data. IMHO the original post is unjustified paranoia, rather than reasonable caution. Paul ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] remark about http://www.freeoszoo.org 2004-10-03 17:47 ` Karl Magdsick 2004-10-03 19:21 ` Lennert Buytenhek @ 2004-10-04 4:09 ` Brad Campbell 1 sibling, 0 replies; 7+ messages in thread From: Brad Campbell @ 2004-10-04 4:09 UTC (permalink / raw) To: Karl Magdsick, qemu-devel Karl Magdsick wrote: > As a note to anyone planning on uploading QEMU disk images to Free OS > Zoo, Free OS Zoo's suggested way of creating disk images does not (in > the general case) blank out the unused space in the disk image. As a > result, the image will likely contain parts of deleted files from the > host OS. This will reduce compressability of the disk images and may > cause the disk images to contian sensitive information, such as > passwords and credit card numbers. > > This isn't a problem unless you think you might possibly give the disk > image to someone else in the future. > I think perhaps you should go back and do some reading on sparse files, what they are and how they work before jumping to such conclusions. Brad ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-10-04 11:50 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-10-02 13:16 [Qemu-devel] remark about http://www.freeoszoo.org albi 2004-10-03 17:47 ` Karl Magdsick 2004-10-03 19:21 ` Lennert Buytenhek 2004-10-04 6:50 ` Karl Magdsick 2004-10-04 11:29 ` Lennert Buytenhek 2004-10-04 11:43 ` Paul Brook 2004-10-04 4:09 ` Brad Campbell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).