GPT writing of unknown partition uuids

GPT writing of unknown partition uuids

[Scott Moser]

Hi,

I came to send the previous patch after realizing that the following is a
lossy operation if the GUID type for the partition is not known to sfdisk.

$ img="/tmp/my.img"
$ size="100M"

$ rm -f "$img"
$ truncate --size "$size" "$img"
$ GPT_PREP="9E1A2D38-C612-4316-AA26-8B49521E5A8B"
$ PT1_UUID="7EB5EBCA-1611-431B-9C80-D87300B41B3B"
$ LABEL_UUID="3C5AD185-CFBF-480D-B80C-AD089E073AC9"

$ sfdisk "$img" <<EOF
label: gpt
label-id: $LABEL_UUID
unit: sectors
1 : start=2048, size=16384, type=$GPT_PREP, uuid=$PT1_UUID
EOF

If sfdisk does not know the uuid provided, it silently falls back to
0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem).

It seems like if the user provided you with a GUID, sfdisk should trust
them, or at very least exit failure if it refuses to use the provided
GUID.

Thoughts?
Scott

Re: GPT writing of unknown partition uuids

[Dale R. Worley]

Scott Moser <smoser@ubuntu.com> writes:
> If sfdisk does not know the uuid provided, it silently falls back to
> 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem).
> 
> It seems like if the user provided you with a GUID, sfdisk should trust
> them, or at very least exit failure if it refuses to use the provided
> GUID.

Ugh, you're right!  Silent disobedience is pernicious.

Dale

Re: GPT writing of unknown partition uuids

[Scott Moser]

On Tue, 14 Jul 2015, Dale R. Worley wrote:

> Scott Moser <smoser@ubuntu.com> writes:
> > If sfdisk does not know the uuid provided, it silently falls back to
> > 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem).
> >
> > It seems like if the user provided you with a GUID, sfdisk should trust
> > them, or at very least exit failure if it refuses to use the provided
> > GUID.
>
> Ugh, you're right!  Silent disobedience is pernicious.

My hack / "will this work" to fdisk_label_parse_parttype seemed to get a
functional fdisk_new_unknown_parttype that would be used.

diff --git a/libfdisk/src/parttype.c b/libfdisk/src/parttype.c
index aedf4e8..bda850a 100644
--- a/libfdisk/src/parttype.c
+++ b/libfdisk/src/parttype.c
@@ -335,6 +335,7 @@ struct fdisk_parttype *fdisk_label_parse_parttype(
 		if (ret)
 			goto done;

+		typestr = str;
 		/* maybe specified by order number */
 		errno = 0;
 		i = strtol(str, &end, 0);
@@ -347,7 +348,7 @@ struct fdisk_parttype *fdisk_label_parse_parttype(

 	ret = fdisk_new_unknown_parttype(code, typestr);
 done:
-	DBG(PARTTYPE, ul_debugobj(ret, "returns parsed '%s' partition type", ret->name));
+	DBG(PARTTYPE, ul_debugobj(ret, "returns parsed '%s' partition type (%s)", ret->name, ret->typestr));
 	return ret;
 }

Re: GPT writing of unknown partition uuids

[Karel Zak]

On Tue, Jul 14, 2015 at 04:16:56PM -0400, Scott Moser wrote:
> It seems like if the user provided you with a GUID, sfdisk should trust
> them, or at very least exit failure if it refuses to use the provided
> GUID.
> 
> Thoughts?

It's bug, the "unknown" partition type is expected. Fixed in git tree:

# sfdisk -ql /dev/sdc
Device     Start     End Sectors  Size Type
/dev/sdc1   2048 1023966 1021919  499M Linux filesystem


# sfdisk --part-type /dev/sdc 1 $(uuidgen)
...


# sfdisk -ql /dev/sdc
Device     Start     End Sectors  Size Type
/dev/sdc1   2048 1023966 1021919  499M unknown


Thanks for your report!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: GPT writing of unknown partition uuids

[Scott Moser]

On Wed, 15 Jul 2015, Karel Zak wrote:

> On Tue, Jul 14, 2015 at 04:16:56PM -0400, Scott Moser wrote:
> > It seems like if the user provided you with a GUID, sfdisk should trust
> > them, or at very least exit failure if it refuses to use the provided
> > GUID.
> >
> > Thoughts?
>
> It's bug, the "unknown" partition type is expected. Fixed in git tree:
>
> # sfdisk -ql /dev/sdc
> Device     Start     End Sectors  Size Type
> /dev/sdc1   2048 1023966 1021919  499M Linux filesystem
>
>
> # sfdisk --part-type /dev/sdc 1 $(uuidgen)
> ...
>
>
> # sfdisk -ql /dev/sdc
> Device     Start     End Sectors  Size Type
> /dev/sdc1   2048 1023966 1021919  499M unknown
>
>
> Thanks for your report!
Thanks for the quick fix.

Is it sane for me to assume this is fixed in any version of
  util-linux > 2.26.2 ?

Re: GPT writing of unknown partition uuids

[Karel Zak]

On Wed, Jul 15, 2015 at 10:56:48AM -0400, Scott Moser wrote:
> Is it sane for me to assume this is fixed in any version of
>   util-linux > 2.26.2 ?

 Sure, I'd like to release v2.27 in Aug.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: GPT writing of unknown partition uuids

[Vadim Kochan]

On Wed, Jul 15, 2015 at 10:56:48AM -0400, Scott Moser wrote:
> On Wed, 15 Jul 2015, Karel Zak wrote:
> 
> > On Tue, Jul 14, 2015 at 04:16:56PM -0400, Scott Moser wrote:
> > > It seems like if the user provided you with a GUID, sfdisk should trust
> > > them, or at very least exit failure if it refuses to use the provided
> > > GUID.
> > >
> > > Thoughts?
> >
> > It's bug, the "unknown" partition type is expected. Fixed in git tree:
> >
> > # sfdisk -ql /dev/sdc
> > Device     Start     End Sectors  Size Type
> > /dev/sdc1   2048 1023966 1021919  499M Linux filesystem
> >
> >
> > # sfdisk --part-type /dev/sdc 1 $(uuidgen)
> > ...
> >
> >
> > # sfdisk -ql /dev/sdc
> > Device     Start     End Sectors  Size Type
> > /dev/sdc1   2048 1023966 1021919  499M unknown
> >
> >
> > Thanks for your report!
> Thanks for the quick fix.
> 
> Is it sane for me to assume this is fixed in any version of
>   util-linux > 2.26.2 ?
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Would you please test a following fix ?

diff --git a/misc/ss.c b/misc/ss.c
index 03f92fa..3a826e4 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix *prefix, char **ptr)
 
 static inline char *sock_addr_get_str(const inet_prefix *prefix)
 {
-    char *tmp ;
-    memcpy(&tmp, prefix->data, sizeof(char *));
+    char *tmp;
+    memcpy(&tmp, &prefix->data[0], sizeof(char *));
     return tmp;
 }
 

Re: GPT writing of unknown partition uuids

[Vadim Kochan]

oops wrong place ...

On Wed, Jul 15, 2015 at 6:09 PM, Vadim Kochan <vadim4j@gmail.com> wrote:
> On Wed, Jul 15, 2015 at 10:56:48AM -0400, Scott Moser wrote:
>> On Wed, 15 Jul 2015, Karel Zak wrote:
>>
>> > On Tue, Jul 14, 2015 at 04:16:56PM -0400, Scott Moser wrote:
>> > > It seems like if the user provided you with a GUID, sfdisk should trust
>> > > them, or at very least exit failure if it refuses to use the provided
>> > > GUID.
>> > >
>> > > Thoughts?
>> >
>> > It's bug, the "unknown" partition type is expected. Fixed in git tree:
>> >
>> > # sfdisk -ql /dev/sdc
>> > Device     Start     End Sectors  Size Type
>> > /dev/sdc1   2048 1023966 1021919  499M Linux filesystem
>> >
>> >
>> > # sfdisk --part-type /dev/sdc 1 $(uuidgen)
>> > ...
>> >
>> >
>> > # sfdisk -ql /dev/sdc
>> > Device     Start     End Sectors  Size Type
>> > /dev/sdc1   2048 1023966 1021919  499M unknown
>> >
>> >
>> > Thanks for your report!
>> Thanks for the quick fix.
>>
>> Is it sane for me to assume this is fixed in any version of
>>   util-linux > 2.26.2 ?
>> --
>> To unsubscribe from this list: send the line "unsubscribe util-linux" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Would you please test a following fix ?
>
> diff --git a/misc/ss.c b/misc/ss.c
> index 03f92fa..3a826e4 100644
> --- a/misc/ss.c
> +++ b/misc/ss.c
> @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix *prefix, char **ptr)
>
>  static inline char *sock_addr_get_str(const inet_prefix *prefix)
>  {
> -    char *tmp ;
> -    memcpy(&tmp, prefix->data, sizeof(char *));
> +    char *tmp;
> +    memcpy(&tmp, &prefix->data[0], sizeof(char *));
>      return tmp;
>  }
>