Add LUKS encrypted partition notes to the GParted Manual about the new
capabilities coming in the next release of GParted.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Shrinking LUKS encryption is only possible while the mapping is open and
active. Therefore the File System Support dialog shows Cross + Tick for
this operation. Add this new combination to the legend.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Switch the remaining create and delete operation description generation
to use the virtual Partition get_filesystem_string() method.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Now that resizing of encrypted file systems is implemented add growing
of the open LUKS mapping as part of the check repair operation.
Resizing an encrypted file system requires the LUKS mapping to be open
to access the file system within; therefore it also requires libparted
and kernel support for online partition resizing. This limits resizing
to the latest distributions with libparted >= 3.2 and kernel >= 3.6.
However growing an open LUKS mapping as part of a check repair operation
doesn't require resizing the partition. Therefore route via offline
grow of LUKS to avoid those extra, unnecessary requirement. This does
mean that offline LUKS grow artificially requires cryptsetup, but that is
not really significant as even opening LUKS requires cryptsetup.
So now checking an encrypted file system on even the oldest
distributions does:
1) runs FSCK on the encrypted file system;
2) grows the encryption volume to fill the partition;
3) grows the file system to fill the encryption mapping.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
While a device-mapper encryption mapping can only be resized while
active, a LUKS volume can inherently be grown while offline because it
doesn't store a size and when started fills the partition. This doesn't
even need the cryptsetup command to do the resizing (just to open the
LUKS volume afterwards which GParted doesn't yet support). Implement
offline growing of LUKS volumes.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Ensure pre-conditions of always or never being passed a Partition object
containing an open LUKS encryption are met for resizing file system and
LUKS encryption methods.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Moving of closed LUKS is simply enabled by luks .move capability being
set and requires no further coding.
Resizing of encrypted file systems requires both the LUKS mapping and
encrypted file system within to be resized in the right order for both
shrinking and growing. To keep the code simple split resizing of plain
and encrypted into separate functions.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Changing the Resize/Move dialog code to also handle PartitionLUKS
objects was considered too complicated. Instead create an unencrypted
equivalent using clone_as_plain(), pass that to the Resize/Move dialog
and finally apply the change back using Partition*::resize().
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Add a resize() method to both Partition and PartitionLUKS classes. They
take a reference Partition object, and update the position, size and
file system usage of *this Partition to match. This is ready for taking
a partition returned from Resize/Move dialog and applying the change.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Implement a specialist PartitionLUKS clone method. Creates a new
Partition object which has the same space usage as the source encrypted
file system, but is a plain file system. Namely, the overhead of the
LUKS header has been added to the file system usage. This is ready for
feeding this representation of the partition to the Resize/Move dialog.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
A partition containing LUKS encryption can only be moved when closed and
the Device Mapper encryption mapping only exists to be resized when
open. As GParted can't yet open or close LUKS encryption these
restrictions have to be adhered to when composing operations. Also as
encrypted partitions are only being resized when open, additionally
libparted and the kernel have to both be capable of resizing a partition
while in use.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Ensure pre-condition of never being passed a Partition object containing
an open LUKS encryption mapping is met for copy operation related
methods.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Users will expect to see that copying of LUKS is available in the File
System Support dialog, even if technically what is implemented is
copying of the file system within an open encryption mapping. There is
no other reason to do this change as these two previous commits have
fully enabled copying of encrypted content:
Implement copy operation of encrypted file systems (#774814)
Preview copy operation of encrypted file systems (#774818)
Set LUKS .copy capability so that the dialog shows copying availability,
but then disallow copying of closed LUKS. (Checking for the capability
and performing copying the content of an open LUKS encryption mapping is
inherent in Win_GParted::set_valid_operations() and GParted_Core::copy()
in the way that they access the block device containing the file system,
whether encrypted or not).
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Implement the copy operation by making the copy code work with the
Partition object directly containing the file system, instead of the
enclosing PartitionLUKS object containing the LUKS encryption mapping.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Implement composing of the copy paste operation for encrypted file
systems.
Copying a closed LUKS partition would duplicate the LUKS header
containing the UUID, passphrase and master encryption key. From a
security point of view having additional copies of encrypted data with
the same master key is an extra risk, but it all depends on what is
going to happen with that copy. The Cryptsetup FAQ [1] talks about how
to make a backup at the file system level and block level, preferring
file system level with separate encryption if needed. It strongly
recommends separate encryption if the copy is removable or going
off-site [2]. Also in the case of cloning the data, cloning the LUKS
container is strongly discouraged [3].
Therefore copying of encrypted file systems will be implemented by
copying the file system inside an open LUKS encryption mapping and not
by copying a closed LUKS partition.
Also, while creating new LUKS encryption is not yet supported, copying
an encrypted file system into a new partition will not be permitted as
that will always decrypt the data. An encrypted file system will be
allowed to be copied into an existing plain partition, decrypting the
data, or into an existing open encrypted partition, keeping it
encrypted. Pasting over the top of a closed encrypted partition will
remove the LUKS encryption. (This is planned to be removed when
creating and removing LUKS encryption is implemented as part of full
LUKS read-write support).
Remember that when pasting into an existing partition the file system
must fit within the available space and that encryption has overhead
from the LUKS header. Therefore copying from a plain partition into a
partition of the same size with open an encryption mapping will not fit
for space reasons.
[1] The Cryptsetup FAQ, Backup and data Recovery section
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
[2] 6.7 Does a backup compromise security?
"If you do network-backup or tape-backup, I strongly recommend to go the
filesystem backup path with independent encryption, as you typically
cannot reliably delete data in these scenarios, especially in a cloud
setting."
[3] 6.15 Can I clone a LUKS container?
"You can, but it breaks security, because the cloned container has the
same header and hence the same master key. You cannot change the master
key on a LUKS container, even if you change the passphrase(s), the
master key stays the same. That means whoever has access to one of the
clones can decrypt them all, completely bypassing the passphrases.
The right way to do this is to first luksFormat the target container,
then to clone the contents of the source container, with both containers
mapped, i.e. decrypted. You can clone the decrypted contents of a LUKS
container in binary mode, although you may run into secondary issues
with GUIDs in filesystems, partition tables, RAID-components and the
like. These are just the normal problems binary cloning causes.
Note that if you need to ship (e.g.) cloned LUKS containers with a
default passphrase, that is fine as long as each container was
individually created (and hence has its own master key). In this case,
changing the default passphrase will make it secure again."
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Ensure pre-condition of never being passed a Partition object containing
an open LUKS encryption mapping is met for format operation related
methods.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Formatting an existing encrypted partition will format the file system
within the encrypted mapping. Formatting over the top of a closed
encrypted partition will remove the encryption. (The latter is planned
to be prevented when creating and removing LUKS encryption is
implemented as part of full LUKS read-write support).
Composing the format operation inside an open LUKS encryption mapping
also has to account for the size of that mapping and construct a
PartitionLUKS object containing the new file system. Implementing the
operation itself is as simple as passing the Partition object directly
containing the file system, instead of the outer PartitionLUKS object.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Already have:
Utils::get_filesystem_string(FS_EXT2) -> "ext2"
virtual Partition::get_filesystem_string() -> "ext2"
virtual PartitionLUKS::get_filesystem_string() -> "[Encrypted] ext2"
Add these:
Utils::get_encrypted_string() -> "[Encrypted]"
Utils::get_filesystem_string(false, FS_EXT2) -> "ext2"
Utils::get_filesystem_string(true, FS_EXT2) -> "[Encrypted] ext2"
This is ready for use of Utils::get_filesystem_string(true, FS_EXT2)
when composing the preview of a format of an encrypted file system by
Win_GParted::activate_format().
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Adapts the swapon/swapoff, activate/deactivate Volume Group and mount/
unmount file system code to work with the Partition object directly
containing the file system.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Ensure pre-condition of never being passed a Partition object containing
an open LUKS encryption mapping is met for check operation related
methods.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Just update the code describing and implementing the check operation.
No need to update the code composing the operation in
Win_GParted::activate_check() as that is incredibly simple, just cloning
the Partition object and doesn't need changing.
Note that for encrypted file systems this does:
1) runs FSCK on the encrypted file system;
2) grows the file system to fill the encrypted mapping.
At this time it does not grow the encryption mapping to fill the
partition. That will be added after resize/move has been implemented.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Ensure pre-condition of never being passed a Partition object containing
an open LUKS encryption mapping is met for label file system operation
related methods.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Again, just need to change the code when composing, describing and
implementing the operation to query and set the Partition object
directly containing the file system, instead of the enclosing encryption
mapping to make it work.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Ensure pre-condition of never being passed a Partition object containing
an open LUKS encryption mapping is met for change UUID operation related
methods.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
When composing, describing and implementing the operation just need the
code to query and set the Partition object directly containing the file
system, instead of the enclosing encryption mapping to make it work.
The operation details for setting a new UUID on an encrypted ext4 file
system become:
Set a new random UUID on [Encrypted] ext4 file system on /dev/sdb4
+ calibrate /dev/sdb4
+ Set UUID on /dev/mapper/sdb4_crypt to a new, random value
+ tune2fs -U random /dev/mapper/sdb4_crypt
tune2fs 1.41.12 (17-May-2010)
Also note the now documented rule in apply_operation_to_disk() which
says each operation must leave the status of the encryption mapping and
file system as it found it.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
Provide and use a single interface for getting the file system string
for display, regardless of whether the partition is encrypted or the
encryption mapping is active or not.
Example return values for get_filesystem_string() for different types
and states of Partition objects:
1) Plain ext4 file system: -> "ext4"
2) Closed encrypted: -> "[Encrypted]"
3) Open encrypted ext4 file system: -> "[Encrypted] ext4"
This simplifies the code in TreeView_Detail::create_row() which sets the
file system type displayed in the main window. The same method will
then also be used when setting the operation description as each
operation is updated to handle encrypted file systems.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
The previous commit changed how the code behind the main window
retrieved the file system label for display. This is the relevant
changes in TreeView_Detail::create_row():
+ const Partition & filesystem_ptn = partition.get_filesystem_partition();
...
- Glib::ustring temp_filesystem_label = partition.get_filesystem_label();
+ Glib::ustring temp_filesystem_label = filesystem_ptn.get_filesystem_label();
treerow[treeview_detail_columns.label] = temp_filesystem_label;
In the case of an encrypted file system get_filesystem_label() is now
called on the Partition object directly rather than on the outer
Partition object containing the LUKS encryption.
The code behind the Information dialog always obtained and used the
Partition object directly containing the file system to call
get_filesystem_label() since read-only LUKS support was added.
Therefore the virtualised PartitionLUKS::get_filesystem_label() is no
longer needed, so remove it.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
There are multiple cases of code wanting to work with the Partition
object directly containing the file system, regardless of whether it is
within a PartitionLUKS object or not. The code had to do something
similar to this to access it:
const Partition * filesystem_ptn = &partition;
if ( partition.filesystem == FS_LUKS && partition.busy )
filesystem_ptn = &dynamic_cast<const PartitionLUKS *>( &partition )->get_encrypted();
...
// Access Partition object directly containing the file system
filesystem_ptn-> ...
Implement and use virtual accessor get_filesystem_partition() which
allows the code to be simplified like this:
const Partition & filesystem_ptn = partition.get_filesystem_partition();
...
// Access Partition object directly containing the file system
filesystem_ptn. ...
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
In the main window, display the busy status of the file system only
according to whether it is mounted or not, ignoring the status of the
encryption mapping.
Bug 774818 - Implement LUKS read-write actions NOT requiring a
passphrase
More recent versions of blkid don't report an ISO9660 file system on the
whole disk device if partitions can be reports for embedded partitions.
However when querying the whole disk device directly then the expected
ISO9660 file system is reported. For example on CentOS 7 with the
previous ISO images:
# wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/isosize/sample.iso.gz
# dd if=/dev/zero bs=1M of=/dev/sdc
# zcat sample.iso.gz | dd of=/dev/sdc
# blkid -v
blkid from util-linux 2.23.2 (libblkid 2.23.0, 25-Apr-2013)
# blkid | fgrep /dev/sdc
/dev/sdc1: UUID="2013-01-04-22-05-45-00" LABEL="ARCH_201301" TYPE="iso9660" PTTYPE="dos"
# blkid /dev/sdc
/dev/sdc: UUID="2013-01-04-22-05-45-00" LABEL="ARCH_201301" TYPE="iso9660" PTTYPE="dos"
# wget http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/debian-8.6.0-amd64-netinst.iso
# dd if=/dev/zero bs=1M of=/dev/sdc
# dd if=debian-8.6.0-amd64-netinst.iso bs=1M of=/dev/sdc
# blkid | fgrep /dev/sdc
/dev/sdc1: UUID="2016-09-17-14-23-48-00" LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660" PTTYPE="dos"
/dev/sdc2: SEC_TYPE="msdos" UUID="17F3-1162" TYPE="vfat"
# blkid /dev/sdc
/dev/sdc: UUID="2016-09-17-14-23-48-00" LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660" PTTYPE="dos"
This behavioural difference with blkid is probably as a result of newer
versions of udev informing the kernel of the partitions embedded within
the ISO9660 image, and not directly as a result of a change in blkid
itself. Older distributions don't have partition entries for the above
ISO images, but CentOS 7 (with udev 219) and later distributions do have
partition entries:
# fgrep sdc /proc/partitions
8 16 8388608 sdc
8 17 252928 sdc1
8 18 416 sdc2
Fix by ensuring that the blkid FS_Info cache has entries for whole disk
devices, even if each entry has all empty attributes because there is a
partition table and not a recognised file system.
Calling blkid on whole disk devices containing partition tables produces
output like this, with newer versions of blkid:
# blkid /dev/sda
/dev/sda: PTTYPE="dos"
# blkid /dev/sdb
/dev/sdb: PTTYPE="gpt"
This will be loaded into the FS_Info cache as a blank entry for the
device by run_blkid_load_cache(). There will be a path name but all the
other attributes will be blank because there are no TYPE, SEC_TYPE, UUID
or LABEL name value pairs. With older versions of blkid no output is
produced at all. In that case load_fs_info_cache_extra_for_path() will
create the same blank entry with just the path name defined.
Bug 771244 - gparted does not recognize the iso9660 file system in
cloned Ubuntu USB boot drives
ISO9660 images can contain embedded partitions which when encountered on
whole disk drives causes libparted to report various warnings and
errors. For example on CentOS 6 with upgraded libparted 2.4 the
following errors and warnings are encountered with various ISO images.
(Deliberately using an older distribution with older blkid to avoid
another issue with blkid addressed in the following patch).
Libparted error message 1:
# wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/isosize/sample.iso.gz
# dd if=/dev/zero bs=1M of=/dev/sdc
# zcat sample.iso.gz | dd of=/dev/sdc
# blkid -v
blkid from util-linux-ng 2.17.2 (libblkid 2.17.0, 22-Mar-2010)
# blkid | fgrep /dev/sdc
/dev/sdc: LABEL="ARCH_201301" TYPE="iso9660"
# ./gpartedbin /dev/sdc
======================
libparted : 2.4
======================
Invalid partition table - recursive partition on /dev/sdc.
Libparted Error
(-) Invalid partition table - recursive partition on /dev/sdc.
[ Cancel ] [ Ignore ]
Libparted error message 2:
# wget http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/debian-8.6.0-amd64-netinst.iso
# dd if=/dev/zero bs=1M of=/dev/sdc
# dd if=debian-8.6.0-amd64-netinst.iso bs=1M of=/dev/sdc
# blkid | fgrep /dev/sdc
/dev/sdc: LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660"
# ./gpartedbin /dev/sdc
======================
libparted : 2.4
======================
/dev/sdc contains GPT signatures, indicating that it has a GPT
table. However, it does not have a valid fake msdos partition
table, as it should. Perhaps it was corrupted -- possibly by a
program that doesn't understand GPT partition tables. Or perhaps
you deleted the GPT table, and are now using an msdos partition
table. Is this a GPT partition table?
Libparted Warning
/!\ /dev/sdc contains GPT signatures, indicating that it has a GPT
table. However, it does not have a valid fake msdos partition
table, as it should. Perhaps it was corrupted -- possibly by a
program that doesn't understand GPT partition tables. Or
perhaps you deleted the GPT table, and are now using an msdos
partition table. Is this a GPT partition table?
[ Yes ] [ No ]
These messages are because GParted is calling ped_disk_new() to attempt
to read the partition table even before it has tried to recognise the
ISO9660 file system on the whole disk drive. Full call chain is:
set_devices_thread()
set_device_from_disk()
get_device_and_disk()
get_disk()
ped_disk_new()
Fix this by delaying the call to ped_disk_new() until after whole disk
drive recognition has been performed. Replace combined
get_device_and_disk() with separate get_device() and only call
get_disk() after no whole disk drive file system has been recognised.
This is similar to how calibrate_partition() and
erase_filesystem_signatures() are structured to also handle whole disk
drive file systems.
Bug 771244 - gparted does not recognize the iso9660 file system in
cloned Ubuntu USB boot drives
Move code from GParted_Core::set_devices_thread() performing top level
population of each Device object during the scan of the drives into new
set_device_from_disk() method.
Bug 771244 - gparted does not recognize the iso9660 file system in
cloned Ubuntu USB boot drives
Requires blkid.
Note that FS_LUKS was also moved to more closely match the order in
include/Utils.h
Bug 771244 - gparted does not recognize the iso9660 file system in
cloned Ubuntu USB boot drives
Glibc 2.25 is deprecating <sys/types.h> including <sys/sysmacros.h>.
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dbab6577c6684c62bd2521c1c29dc25c3cac966f
Deprecate inclusion of <sys/sysmacros.h> by <sys/types.h>
Building on Fedora Rawhide with Glibc 2.24.90 produces these warnings:
BlockSpecial.cc:64:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "major", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"major", you should undefine it after including <sys/types.h>.
m_major = major( sb.st_rdev );
^~~~~~~~~~~~~~~~~~~~
BlockSpecial.cc:65:13: warning: In the GNU C Library, "minor" is defined
by <sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "minor", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"minor", you should undefine it after including <sys/types.h>.
m_minor = minor( sb.st_rdev );
^~~~~~~~~~~~~~~~~~~~
Code needing major and minor macros should include <sys/sysmacros.h>
directly. As both Glibc and musl-libc have always provided this header
and GParted is a Linux only application, just always include the header
and don't bother with an autoconf check for its existence.
Bug 776173 - Missing sys/sysmacros.h #include, needed for experimental
glibc versions
The details for a file system shrink operation look like this with the
"shrink file system" message being missing:
Shrink /dev/sdb1 from 128.00 MiB to 100.00 MiB
+ calibrate /dev/sdb1
+ check file system on /dev/sdb1 for errors and (if possible) fix them
+ e2fsck -f -y -v -C 0 /dev/sdb1
+ resize2fs -p /dev/sdb1 102400K
+ shrink partition from 128.00 MiB to 100.00 MiB
This earlier commit [1] in the series dropped the message while moving
code from resize_filesystem() to shrink_filesystem(). Re-add the
message back.
[1] a0158abbeb
Refactor resizing file system apply methods (#775932)
Bug 775932 - Refactor mostly applying of operations
Explain when and why shrinking file systems is disallowed.
Unnecessary history. Check added in 2004-12-15:
d100935b55
:Set_Valid_Operations()
Comment later added in 2006-07-30:
677a21f50a
improved errorhandling a bit. At the initialscan we store errors/warnings
FileSystem::resize() (and derived) is only ever called from a single
location and always with the fill_partition argument supplied [1].
Therefore providing a default for the argument is unnecessary. So
remove it.
[1] Since these two commits from 2006-06-17, before GParted 0.3.0, which
added resize_filesystem() and maximize_filesystem() methods to wrap
calls to p_filesystem->resize() into a single location:
08245cd08c
cleanups in the core and the fs'es (resize)
2d7fb5700b
more cleanups in the core and the fs'es (these changelogs are getting
It made the code look a little messy, is easily resolved in the build
system and made the dependencies more complicated than needed. Each
GParted header was tracked via multiple different names (different
numbers of "../include/" prefixes). For example just looking at how
DialogFeatures.o depends on Utils.h:
$ cd src
$ make DialogFeatures.o
$ egrep ' [^ ]*Utils.h' .deps/DialogFeatures.Po
../include/DialogFeatures.h ../include/../include/Utils.h \
../include/../include/../include/../include/../include/../include/Utils.h \
../include/../include/../include/Utils.h \
After removing "../include/" from the GParted header #includes, just
need to add "-I../include" to the compile command via the AM_CPPFLAGS in
src/Makefile.am. Now the dependencies on GParted header files are
tracked under a single name (with a single "../include/" prefix). Now
DialogFeatures.o only depends on a single name to Utils.h:
$ make DialogFeatures.o
$ egrep ' [^ ]*Utils.h' .deps/DialogFeatures.Po
../include/DialogFeatures.h ../include/Utils.h ../include/i18n.h \
