linux-kernel - Re: Tux3 Report: Initial fsck has landed

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:	Tue, 19 Mar 2013 21:08:39 -0700
From:	Daniel Phillips <daniel.raymond.phillips@...il.com>
To:	David Lang <david@...g.hm>
Cc:	Martin Steigerwald <Martin@...htvoll.de>, tux3@...nq.net,
	"Theodore Ts'o" <tytso@....edu>,
	"Darrick J. Wong" <darrick.wong@...cle.com>,
	linux-kernel@...r.kernel.org, tux3@...3.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: Tux3 Report: Initial fsck has landed

On Tue, Mar 19, 2013 at 9:04 PM, David Lang <david@...g.hm> wrote:
> On Wed, 20 Mar 2013, Martin Steigerwald wrote:
>
>> Am Dienstag, 29. Januar 2013 schrieb Daniel Phillips:
>>>
>>> On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o <tytso@....edu> wrote:
>>>>
>>>> On Mon, Jan 28, 2013 at 04:20:11PM -0800, Darrick J. Wong wrote:
>>>>>
>>>>> On Mon, Jan 28, 2013 at 03:27:38PM -0800, David Lang wrote:
>>>>>>
>>>>>> The situation I'm thinking of is when dealing with VMs, you make a
>>>>>> filesystem image once and clone it multiple times. Won't that end up
>>>>>> with the same UUID in the superblock?
>>>>>
>>>>> Yes, but one ought to be able to change the UUID a la tune2fs
>>>>> -U.  Even still... so long as the VM images have a different UUID
>>>>> than the fs that they live on, it ought to be fine.
>>>>
>>>> ... and this is something most system administrators should be
>>>> familiar with.  For example, it's one of those things that Norton
>>>> Ghost when makes file system image copes (the equivalent of "tune2fs
>>>> -U random /dev/XXX")
>>>
>>> Hmm, maybe I missed something but it does not seem like a good idea
>>> to use the volume UID itself to generate unique-per-volume metadata
>>> hashes, if users expect to be able to change it. All the metadata hashes
>>> would need to be changed.
>>
>> I believe that is what BTRFS is doing.
>>
>> And yes, AFAIK there is no easy way to change the UUID of a BTRFS
>> filesystems
>> after it was created.
>
> In a world where systems are cloned, and many VMs are started from one
> master copy of a filesystem, a UUID is about as far from unique as anything
> you can generate.
>
> BTRFS may have this problem, but why should Tux3 copy the problem?

Tux3 won't copy that problem. We have enough real problems to deal with
as it is, without manufacturing new ones.

Regards,

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