6 captures

03 May 2019 - 28 Oct 2025

Apr	MAY	Jun
	03
2018	2019	2020

success

fail

About this capture

TIMESTAMPS

Debian Bug report logs - #770211
/sbin/fdisk: add LUKS partition type code to fdisk

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Drake Wilson <drake@dasyatidae.net>

To: submit@bugs.debian.org

Subject: /sbin/fdisk: add LUKS partition type code to fdisk

Date: Wed, 19 Nov 2014 12:11:08 -0600

Package: util-linux
Version: 2.25.2-2
Severity: wishlist
File: /sbin/fdisk

Greetings!  According to [1], LUKS partitions on MBR disklabels can be
assigned the type code e8.  If this is correct, it would be nice if
this could be added to fdisk's named type list, probably as "Linux
encrypted" or similar.  I've submitted a similar request for gdisk at
#769631.

   ---> Drake Wilson

[1] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages util-linux depends on:
ii  init-system-helpers  1.21
ii  initscripts          2.88dsf-57
ii  libblkid1            2.25.2-2
ii  libc6                2.19-13
ii  libmount1            2.25.2-2
ii  libncurses5          5.9+20140913-1
ii  libpam0g             1.1.8-3.1
ii  libselinux1          2.3-2
ii  libslang2            2.3.0-2
ii  libsmartcols1        2.25.2-2
ii  libtinfo5            5.9+20140913-1
ii  libuuid1             2.25.2-2
ii  lsb-base             4.1+Debian13+nmu1
ii  tzdata               2014i-1
ii  zlib1g               1:1.2.8.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools          3.0.26-4
ii  kbd                 1.15.5-2
ii  util-linux-locales  2.25.2-2

-- no debconf information

Message #10 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: Drake Wilson <drake@dasyatidae.net>, 770211@bugs.debian.org

Subject: Re: Bug#770211: /sbin/fdisk: add LUKS partition type code to fdisk

Date: Wed, 19 Nov 2014 21:11:58 +0100

Hello Drake Wilson.

On Wed, Nov 19, 2014 at 12:11:08PM -0600, Drake Wilson wrote:
> Package: util-linux
> Version: 2.25.2-2
> Severity: wishlist
> File: /sbin/fdisk
> 
> Greetings!  According to [1], LUKS partitions on MBR disklabels can be
> assigned the type code e8.  If this is correct, it would be nice if
> this could be added to fdisk's named type list, probably as "Linux
> encrypted" or similar.  I've submitted a similar request for gdisk at
> #769631.
> 
>    ---> Drake Wilson
> 
> [1] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

Could you please ask about this on the upstream development mailing list?

util-linux@vger.kernel.org

Regards,
Andreas Henriksson

Message #15 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Drake Wilson <drake@dasyatidae.net>

To: util-linux@vger.kernel.org

Cc: 770211@bugs.debian.org

Subject: LUKS partition types, redux

Date: Wed, 19 Nov 2014 14:59:01 -0600

Good day, folks of util-linux;

Summary: I would like to reopen the suggestion to add LUKS partition type codes
for MBR and for GPT to util-linux's fdisk.  In a previous discussion, it was
said that since Linux does not interpret partition types, there is no need for
this, but concrete data loss has now occurred as a result of a related bug in
other software combined with the lack of a user-visible LUKS type in a similar
partitioning program, and I believe that warrants re-examination of the situation.

Details:

I recently submitted Debian wishlist bug #770211 [1] suggesting to add e8 as the
MBR type code for LUKS to fdisk, per [2], mainly for consistency with my wishlist
item for gdisk at [3].  I was asked to ask about it here.  (I see now that fdisk
also handles GPT disklabels, which I wasn't previously aware of.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770211
[2] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769631

I see now that there was a thread in January starting at [4] (message-ID
1390934933.15213.17.camel@heisenberg.scientia.net) about this, and the overall
result seemed to be that since Linux ignores partition type codes, there is
no reason to provide one for LUKS volumes.  The counterargument (which I agree
with) was roughly that since the type code slots exist in the first place, it
would be better to help the user semantically align them with the partition
contents, to prevent future issues from other type codes being used instead and
then misinterpreted by other systems.

[4] http://marc.info/?l=util-linux-ng&m=139093540719399&w=2

I would like to point out additional concrete evidence for the counterargument
now, in terms of harm minimization.  I previously tagged LUKS volumes on GPT with
a type code corresponding to the underlying volume type, as the closest thing I
could find (and a straw poll of some other Linux sysadmins I know says some of them
do the same).  I recently submitted Debian bug #768897 [5] in which partman-lvm,
a component of the Debian installer, overaggressively interprets the LVM type as a
normative request to make the partition contain an LVM PV, thus destroying all of
my existing LVM-on-LUKS volumes.  While I firmly believe that this is a bug in
partman-lvm and not in util-linux, had I used util-linux's fdisk to make the
partition tables, the presentation of a LUKS type code there would have
prevented significant data loss in this case.  (In my case, I used gdisk, but
I'm taking it up with them separately.)

[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768897

I would thus like to re-propose adding a LUKS type.  Alternatively, if a LUKS
type is still considered a bad idea, I would like to suggest allocating a GPT ID
analogous to the "da = Non-FS data" MBR type code, which would at least allow the
user to choose a fallback that has a known null semantic, rather than tagging their
volumes with some arbitrary ID that may be misinterpreted; that would help avert
analogous problems for future types as well.

(I also believe more philosophically that the user should be supported in the
possibility of integrating with other partition management systems that may wish
to detect LUKS and do something special with it, without requiring all other such
systems to incorporate a blkid-like system for checking in several places for the
"basic nature" of a volume.  I mention this only for the record, since the previous
thread suggests the util-linux maintainers don't agree with this.)

Thanks for any (polite) replies.

   ---> Drake Wilson

Message #22 received at 770211@bugs.debian.org (full text, mbox, reply):

From: worley@alum.mit.edu (Dale R. Worley)

To: Drake Wilson <drake@dasyatidae.net>

Cc: util-linux@vger.kernel.org, 770211@bugs.debian.org

Subject: Re: LUKS partition types, redux

Date: Wed, 19 Nov 2014 17:24:43 -0500

> From: Drake Wilson <drake@dasyatidae.net>
> 
> Summary: I would like to reopen the suggestion to add LUKS partition
> type codes for MBR and for GPT to util-linux's fdisk.

It certainly makes sense to me.

This raises the related question of whether there should be codes to
identify the partition type inside the LUKS partition.  That is, the
partition table code identifies the partition as a LUKS partition, but
once one has supplied the keys for LUKS encryption, is there any way
to tell the type of the encrypted partition without testing for magic
numbers (using "file" or the like)?

I suppose there aren't enough type codes in MBR to allow separately
identifying "ext4 inside LUKS", but with GPT it would be possible, and
even could be done systematically.  E.g., if the UUID for a partition
type is XXX, then the partition type for that type inside of LUKS is
MD5("LUKS" XXX)...

Then again, perhaps you would not want to reveal the type of the
encrypted partition.

Dale

Message #27 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Phillip Susi <psusi@ubuntu.com>

To: "Dale R. Worley" <worley@alum.mit.edu>, 770211@bugs.debian.org, Drake Wilson <drake@dasyatidae.net>

Cc: util-linux@vger.kernel.org

Subject: Re: Bug#770211: LUKS partition types, redux

Date: Thu, 20 Nov 2014 11:43:02 -0500

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

On 11/19/2014 5:24 PM, Dale R. Worley wrote:
> This raises the related question of whether there should be codes
> to identify the partition type inside the LUKS partition.  That is,
> the partition table code identifies the partition as a LUKS
> partition, but once one has supplied the keys for LUKS encryption,
> is there any way to tell the type of the encrypted partition
> without testing for magic numbers (using "file" or the like)?

Linux doesn't pay any attention to partition type codes anyhow and
just uses blkid to identify the contents.

> I suppose there aren't enough type codes in MBR to allow
> separately identifying "ext4 inside LUKS", but with GPT it would be
> possible, and even could be done systematically.  E.g., if the UUID
> for a partition type is XXX, then the partition type for that type
> inside of LUKS is MD5("LUKS" XXX)...
> 
> Then again, perhaps you would not want to reveal the type of the 
> encrypted partition.

That too.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUbhoWAAoJEI5FoCIzSKrwfZAH/AnTDFG8Nes4Sa+cKebZs9D/
Atf7SrWYQFy++p0o0sNKcSIrdjHghIGEzq8oTZ5pBgnEfu94/uTATUSGSFum7bqL
3ZYPgKNGi7SOj/Oc03p+Tzadjk01gpHUQMcj8jcHJUbrJheLCssPyB558vA5Vqrz
D8bLbOz9JmoDQ+zpWrachKv3+7XAfh0ri54tKsEmNFKN3LOhrxyoVfIGIJf+MFQK
kssPT/ZKD3W/PEBTaI/pcwaCo1+vdR2JYiy4ODBQy7LMfvvw97N3aZEKgRGgLudF
NWApQR7AZLxjD2YllE0NI2NBeq4/8DgLicwnnJSqdHvKFKlbwC0Iq5wIugNjSds=
=s8LS
-----END PGP SIGNATURE-----

Message #32 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Karel Zak <kzak@redhat.com>

To: Drake Wilson <drake@dasyatidae.net>

Cc: util-linux@vger.kernel.org, 770211@bugs.debian.org

Subject: Re: LUKS partition types, redux

Date: Mon, 24 Nov 2014 12:37:33 +0100

On Wed, Nov 19, 2014 at 02:59:01PM -0600, Drake Wilson wrote:
> Summary: I would like to reopen the suggestion to add LUKS partition type codes
> for MBR and for GPT to util-linux's fdisk.  In a previous discussion, it was
> said that since Linux does not interpret partition types, there is no need for
> this, but concrete data loss has now occurred as a result of a related bug in
> other software combined with the lack of a user-visible LUKS type in a similar
> partitioning program, and I believe that warrants re-examination of the situation.

 But it seems that the problem is what details partitioning tools
 provide to end-users rather than problem with data within disk
 labels. I don't see problem to add FS type column to fdisk(s) (it's
 already linked with libblkid).

> I would thus like to re-propose adding a LUKS type.  Alternatively, if a LUKS
> type is still considered a bad idea, I would like to suggest allocating a GPT ID
> analogous to the "da = Non-FS data" MBR type code, which would at least allow the
> user to choose a fallback that has a known null semantic, rather than tagging their
> volumes with some arbitrary ID that may be misinterpreted; that would help avert
> analogous problems for future types as well.

 You want to make a connection between partition type and partition
 format (FS, LUKS, LVM...). This idea is more than 30years old and it
 has been always fragile and introduced for poorly designed systems
 (kernels and boot loaders). 
 
 The current trend is to use partition type to define for what purpose
 we want to use the partition (for example "this is /home")
 independently on partition format. 
 
 For example systemd is able to generate on the fly mount table
 according to GPT partition types (so we have type for root and
 /home). All this is independent on FS/LUKS/etc. The same GUID is for
 XFS, ext4 ... this concept is not compatible with your idea.

 BTW, LUKS (and also XFS) is one of well designed on-disk formats
 where magic string is at the begin of the device, so all you need is
 one seek()+read().

 Anyway, I'd like to minimize number of situations when we depend
 on GPT/MBR partition types at all.

> (I also believe more philosophically that the user should be supported in the
> possibility of integrating with other partition management systems that may wish
> to detect LUKS and do something special with it, without requiring all other such
> systems to incorporate a blkid-like system for checking in several places for the
> "basic nature" of a volume.  I mention this only for the record, since the previous
> thread suggests the util-linux maintainers don't agree with this.)

 This is about partitioning tools, not about on-disk disk label data.


    Karel

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

Message #37 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Drake Wilson <drake@dasyatidae.net>

To: Karel Zak <kzak@redhat.com>

Cc: util-linux@vger.kernel.org, 770211@bugs.debian.org

Subject: Re: LUKS partition types, redux

Date: Mon, 24 Nov 2014 06:09:02 -0600

Firstly: thank you very much for engaging in a reasonable discussion about this.

Karel Zak wrote:
> On Wed, Nov 19, 2014 at 02:59:01PM -0600, Drake Wilson wrote:
>> Summary: I would like to reopen the suggestion to add LUKS partition type codes
>> for MBR and for GPT to util-linux's fdisk.  In a previous discussion, it was
>> said that since Linux does not interpret partition types, there is no need for
>> this, but concrete data loss has now occurred as a result of a related bug in
>> other software combined with the lack of a user-visible LUKS type in a similar
>> partitioning program, and I believe that warrants re-examination of the situation.
> 
>  But it seems that the problem is what details partitioning tools
>  provide to end-users rather than problem with data within disk
>  labels. I don't see problem to add FS type column to fdisk(s) (it's
>  already linked with libblkid).

I don't quite understand the relation of this paragraph to what I was talking
about.  The case of data loss via partman-lvm wasn't related to what fdisk
would have presented to me, but what the disklabel presented to partman-lvm
as a result of the choices fdisk would have presented.

>  You want to make a connection between partition type and partition
>  format (FS, LUKS, LVM...). This idea is more than 30years old and it
>  has been always fragile and introduced for poorly designed systems
>  (kernels and boot loaders). 

It's not quite that I _want_ to make such a connection, more that I think it
has already been made and the current interop situation is suboptimal; see
below.  I would be quite happy as well with a single "Linux other" type
instead of a LUKS-specific type.

>  The current trend is to use partition type to define for what purpose
>  we want to use the partition (for example "this is /home")
>  independently on partition format. 

I can see some of that, yes.  I've only recently encountered this.  This can
somewhat conflict with the purpose of disk encryption, incidentally, which
tends to want to keep those subdivisions hidden if possible (thus LUKS+LVM
being a common setup).  I'm not opposed to the idea being around; _requiring_
it would conflict with my goals, but I don't see any evidence of that, so
let's put that away.

>  Anyway, I'd like to minimize number of situations when we depend
>  on GPT/MBR partition types at all.

So, my more concrete concern here is not in places where Linux or util-linux
read partition type codes; it is where fdisk or a similar utility writes them,
and some other program entirely reads them.  In the bad case I ran into, the
"some other system" happened to be partman-lvm from Debian, but it could just
as well be something else.

Here's the specific scenario: imagine I'm a Linux sysadmin who is writing a
disklabel for a new disk which will contain a LUKS volume.  (The volume does
not necessarily correspond to any of the "usage" types you mentioned, and I
may not want to expose that information anyway.)  The type code field in MBR
or GPT exists already; I cannot simply remove it, and there is no null value.
What value do I type in for that field?

The likely chain of events, if I'm using fdisk or a similar tool, is that I
look up the list of type codes included in that tool and pick the "closest"
one.  If there is no LUKS type, and no "Linux other" or "other" type in
general, I'm likely to wind up picking one of the existing Linux types.
This risks the disk being plugged into a system that misinterprets the type,
because those other types are _notionally_ meaningful even if the core Linux
kernel and utilities don't care much.

Adding a LUKS type to the table means I can pick that, and if Linux, cryptsetup,
etc. never read it, that's fine---the point is that no _other_ system will read
it as something it wasn't meant to be either.  A "Linux other" or "generic /
unspecified" type would also satisfy this, but more weakly because it wouldn't
be as visible (and I would actually love to have all three, honestly).

So it's a combined interop and UI problem, and is related to the disklabel data
itself.  And my main goal in participating here is to help avoid other users
running into similar problems to what I did if they write disklabels using fdisk,
by reducing the risk of accidentally encouraging the user to trigger aggressive
interpretation by other software, even if that other software should not have
made such assumptions in the first place.

Does that help at all?

   ---> Drake Wilson

Message #42 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Phillip Susi <psusi@ubuntu.com>

To: Karel Zak <kzak@redhat.com>, Drake Wilson <drake@dasyatidae.net>

Cc: util-linux@vger.kernel.org, 770211@bugs.debian.org

Subject: Re: LUKS partition types, redux

Date: Mon, 24 Nov 2014 09:42:50 -0500

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

On 11/24/2014 6:37 AM, Karel Zak wrote:
> The current trend is to use partition type to define for what
> purpose we want to use the partition (for example "this is /home") 
> independently on partition format.

I wouldn't call this bone headed idea of redhat's a trend.  Using
partition table type codes to decide to auto mount in particular parts
of the filesystem is such a brain damaged idea, those who thought it
up need beaten with a clue-by-four and its use needs to be *strongly*
discouraged.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc0PqAAoJEI5FoCIzSKrwF3AIAKsduxIzyXOqSlCf0emWc/m3
r/QmAMqyFG5ua1msWmAQaeTTnSFYqwyf4xubIQay8PTd0ruT7Hq/rusu4DCS1aQ1
fecZQhTQi/HHBbZ3mM8w472IB2PM5qDNEDDwZkgbOCpBoEByeZUZFqq+stFSakoD
CHc4sVqHj5FPA3HRq+XuCfqhawc3TcGaO40J0qr0c+7vMm1cAHLIAjifRR8WNrnf
UNk+kDfZJwixaL45t/YcHx001FNJO9Aitj42KV5k4cHke2wAmcmSVj4T9k0NgoCE
TfeDbJrhuQPtJ/V1/oE7q3aH9agppucuEcIjW5Y4ICnqgCeydwlfVfx+FMlVLTk=
=xHEg
-----END PGP SIGNATURE-----

Message #47 received at 770211@bugs.debian.org (full text, mbox, reply):

From: Karel Zak <kzak@redhat.com>

To: Phillip Susi <psusi@ubuntu.com>

Cc: Drake Wilson <drake@dasyatidae.net>, util-linux@vger.kernel.org, 770211@bugs.debian.org

Subject: Re: LUKS partition types, redux

Date: Mon, 24 Nov 2014 16:46:04 +0100

On Mon, Nov 24, 2014 at 09:42:50AM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/24/2014 6:37 AM, Karel Zak wrote:
> > The current trend is to use partition type to define for what
> > purpose we want to use the partition (for example "this is /home") 
> > independently on partition format.
> 
> I wouldn't call this bone headed idea of redhat's a trend.  Using
> partition table type codes to decide to auto mount in particular parts
> of the filesystem is such a brain damaged idea, those who thought it
> up need beaten with a clue-by-four and its use needs to be *strongly*
> discouraged.

 well, it's designed for auto-generated fstab-less systems like
 containers/virt images, etc. I'm not big fan of this feature, but for
 some use cases it makes sense. (And it's systemd upstream decision.)

 Anyway, use partition type for "usage" makes more sense than for "fs-type".

    Karel

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

Message #52 received at 770211@bugs.debian.org (full text, mbox, reply):

From: worley@alum.mit.edu (Dale R. Worley)

To: Karel Zak <kzak@redhat.com>

Cc: psusi@ubuntu.com, drake@dasyatidae.net, util-linux@vger.kernel.org, 770211@bugs.debian.org

Subject: Re: LUKS partition types, redux

Date: Tue, 25 Nov 2014 10:20:40 -0500

> From: Karel Zak <kzak@redhat.com>

>  well, it's designed for auto-generated fstab-less systems like
>  containers/virt images, etc. I'm not big fan of this feature, but for
>  some use cases it makes sense.

I thought that's what filesystem "label" values were for.

>  (And it's systemd upstream decision.)

I've never run into something from systemd that I didn't consider
bizarre and horrible, designed to solve problems I don't have at the
cost of making my life worse.

Dale

Send a report that this bug log contains spam.