linux-ext4 - Re: [PATCH] libblkid: support for GUID Partition Table (GPT), please?

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: <87hbm6k5g9.fsf@violet.siamics.net>
Date:	Mon, 17 May 2010 20:45:10 +0700
From:	Ivan Shmakov <ivan@...n.uusia.org>
To:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] libblkid: support for GUID Partition Table (GPT), please?

>>>>> Karel Zak <kzak@...hat.com> writes:
>>>>> Ivan Shmakov <ivan@...n.uusia.org> writes:

 >>> GPT contains a supposed to be unique “Disk GUID” field, which allows
 >>> for the media bearing such a partition table to be identified.

 > The devel version of libblkid from util-linux-ng supports partition
 > tables parsing, and the partition name (GPT nad Mac) and partition
 > UUID (only GPT) are exported to udev.

	I don't quite understand how udev is tied here, but please note
	that the UUID I was talking above is the one associated with the
	partition table as a whole, not with a particular partition.

	(Huh?  util-linux-ng has its own libblkid?  And, BTW, any chance
	of having the changes accepted into e2fsprogs?)

	Such a UUID allows for removable media to be identified, which,
	in turn, allows for automated backups for such media.
	(Consider, e. g., that one has a bunch of bootable USB flash
	drives.  From time to time, the OS'es are upgraded; and there
	may be problems with newer versions.  The possibility of
	restoring the bootable image to the state it had at a certain
	time could then become extremly handy.)

	(Actually, I've just finished with the design of such a backup
	scheme, and it relies on the media — or partition table —
	UUID's, Sleuthkit and, to preserve disk space, Jigdo.  Hopefully
	I'd be able to describe it at my “hacks collection” [1] soon.)

[1] http://lhc.am-1.org/lhc/users/ivan_shmakov/

 > For example:

 > # blkid -p -o udev /dev/sdb1
 > ID_PART_ENTRY_SCHEME=gpt
 > ID_PART_ENTRY_NAME=ThisIsName
 > ID_PART_ENTRY_UUID=bc10cf1d-7e63-524c-8203-087ae10a820b
 > ID_PART_ENTRY_TYPE=a2a0d0eb-e5b9-3344-87c0-68b6b72699c7
 > ID_PART_ENTRY_NUMBER=1

 > In my TODO list is to support partition identifiers for standard
 > operations like mount/fsck, something like:

 > # mount PARTUUID=bc10cf1d-7e63-524c-8203-087ae10a820b /mnt
 > or
 > # mount PARTLABEL=ThisIsName /mnt

 > Comments?

	Well, to my mind, allowing UUID's that are stored in the
	partition table could be useful in two cases:

	• the filesystem contained on a partition doesn't allow for a
	  UUID;

	• the filesystem is ought to be re-initialized (either to the
	  same filesystem type or any other one) from time to time.

	Although I consider both of the above somewhat unlikely in my
	current practice, I don't see any harm of having such a feature
	“just for a case”.

	The labels are a bit useless, to my mind, since when one does
	mount(8) or fsck(8) by hand, it's usually when one does it with
	the medium attached to a host other than it was usually attached
	to.  There, a name clash is quite likely.

-- 
FSF associate member #7257

Content of type "application/pgp-signature" skipped