Mirrors
/
gparted
mirror of https://gitlab.gnome.org/GNOME/gparted.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gparted/include/PartitionLUKS.h

68 lines
2.0 KiB
C
Raw Normal View History

Add PartitionLUKS class and create objects (#760080) Absolute minimum implementation of a PartitionLUKS class which can be constructed, polymorphically copied and destroyed. Contains an "encrypted" member of type Partition to represent the encrypted file system within the LUKS format. Create PartitionLUKS objects instead of base Partition objects when a LUKS formatted partition is found. Only the base Partition object member values have been populated, and the "encrypted" member remains blank at this point. Bug 760080 - Implement read-only LUKS support
2015-11-11 14:12:39 -07:00
/* Copyright (C) 2015 Mike Fleetwood
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
*/
#ifndef GPARTED_PARTITIONLUKS_H
#define GPARTED_PARTITIONLUKS_H
Remove "../include/" from GParted header #includes 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 \
2016-10-18 16:45:28 -06:00
#include "Partition.h"
#include "Utils.h"
Add PartitionLUKS class and create objects (#760080) Absolute minimum implementation of a PartitionLUKS class which can be constructed, polymorphically copied and destroyed. Contains an "encrypted" member of type Partition to represent the encrypted file system within the LUKS format. Create PartitionLUKS objects instead of base Partition objects when a LUKS formatted partition is found. Only the base Partition object member values have been populated, and the "encrypted" member remains blank at this point. Bug 760080 - Implement read-only LUKS support
2015-11-11 14:12:39 -07:00
Make encrypted Partition objects look like whole disk device ones (#775932) Until now an encryption mapping has been modelled as a Partition object similar to a partition like this: .encrypted.device_path = "/dev/sdb1" .encrypted.path = "/dev/mapper/sdb1_crypt" .encrypted.whole_device = false .encrypted.sector_start = // start of the mapping in the partition .encrypted.sector_end = // end of the mapping in the partition However accessing device_path in the start to end sector range is not equivalent to accessing the partition path as it doesn't provide access to the encrypted data. Therefore existing functions which read and write partition data (GParted file system copying and signature erasure) via libparted using the device_path won't work and will in fact destroy the encrypted data. This could be coded around with an extra case in the device opening code, however it is not necessary. An encrypted block special device /dev/mapper/CRYPTNAME looks just like a whole disk device because it doesn't contain a partition and the file system it contains starts at sector 0 and goes to the end. Therefore model an encryption mapping in the same way a whole disk device is modelled as a Partition object like this: .encrypted.device_path = "/dev/mapper/sdb1_crypt" .encrypted.path = "/dev/mapper/sdb1_crypt" .encrypted.whole_device = true .encrypted.sector_start = 0 .encrypted.sector_end = // size of the encryption mapping - 1 Now GParted file system copy and erasure will just work without any change. Just need to additionally store the LUKS header size, which was previous stored in the sector_start, for use in the get_sectors_{used,unused,unallocated}() calculations. Bug 775932 - Refactor mostly applying of operations
2016-11-08 00:03:09 -07:00
#include <glibmm/ustring.h>
Add PartitionLUKS class and create objects (#760080) Absolute minimum implementation of a PartitionLUKS class which can be constructed, polymorphically copied and destroyed. Contains an "encrypted" member of type Partition to represent the encrypted file system within the LUKS format. Create PartitionLUKS objects instead of base Partition objects when a LUKS formatted partition is found. Only the base Partition object member values have been populated, and the "encrypted" member remains blank at this point. Bug 760080 - Implement read-only LUKS support
2015-11-11 14:12:39 -07:00
namespace GParted
{
class PartitionLUKS : public Partition
{
public:
PartitionLUKS();
virtual ~PartitionLUKS();
virtual PartitionLUKS * clone() const;
Make encrypted Partition objects look like whole disk device ones (#775932) Until now an encryption mapping has been modelled as a Partition object similar to a partition like this: .encrypted.device_path = "/dev/sdb1" .encrypted.path = "/dev/mapper/sdb1_crypt" .encrypted.whole_device = false .encrypted.sector_start = // start of the mapping in the partition .encrypted.sector_end = // end of the mapping in the partition However accessing device_path in the start to end sector range is not equivalent to accessing the partition path as it doesn't provide access to the encrypted data. Therefore existing functions which read and write partition data (GParted file system copying and signature erasure) via libparted using the device_path won't work and will in fact destroy the encrypted data. This could be coded around with an extra case in the device opening code, however it is not necessary. An encrypted block special device /dev/mapper/CRYPTNAME looks just like a whole disk device because it doesn't contain a partition and the file system it contains starts at sector 0 and goes to the end. Therefore model an encryption mapping in the same way a whole disk device is modelled as a Partition object like this: .encrypted.device_path = "/dev/mapper/sdb1_crypt" .encrypted.path = "/dev/mapper/sdb1_crypt" .encrypted.whole_device = true .encrypted.sector_start = 0 .encrypted.sector_end = // size of the encryption mapping - 1 Now GParted file system copy and erasure will just work without any change. Just need to additionally store the LUKS header size, which was previous stored in the sector_start, for use in the get_sectors_{used,unused,unallocated}() calculations. Bug 775932 - Refactor mostly applying of operations
2016-11-08 00:03:09 -07:00
void set_luks( const Glib::ustring & path,
FILESYSTEM fstype,
Sector header_size,
Sector mapping_size,
Byte_Value sector_size,
bool busy );
Display "[Encrypted] FSTYPE" in the File System column (#760080) In the File System column in the GUI, when there is an open dm-crypt mapping, display the colour square for the encrypted file system within and the text as "[Encrypted] FSTYPE". For closed mappings nothing can be known about the encrypted file system within so continue to display a purple square and the text "[Encrypted]". Looks like: Partition | File System ... /dev/sdb3 # ext4 v /dev/sdb4 * # extended /dev/sdb5 # [Encrypted] /dev/sdb6 * # [Encrypted] unknown /dev/sdb7 * # [Encrypted] ext4 Bug 760080 - Implement read-only LUKS support
2015-12-27 06:59:49 -07:00
Partition & get_encrypted() { return encrypted; };
const Partition & get_encrypted() const { return encrypted; };
Populate encrypted Partition member inside PartitionLUKS (#760080) When there exists an open dm-crypt mapping, populate the encrypted Partition object representing the encrypted file system. Bug 760080 - Implement read-only LUKS support
2015-12-23 05:26:17 -07:00
Display usage of encrypted file systems (#760080) There is already the set of methods in the Partition class to report the file system usage. Virtualise them and provide PartitionLUKS specific implementations to calculate the usage of a file system wrapped in LUKS encryption. See the ascii art and comment in PartitionLUKS.cc for the details of those calculations. Bug 760080 - Implement read-only LUKS support
2015-12-28 06:47:12 -07:00
virtual bool sector_usage_known() const;
virtual Sector estimated_min_size() const;
virtual Sector get_sectors_used() const;
virtual Sector get_sectors_unused() const;
virtual Sector get_sectors_unallocated() const;
Display messages for encrypted file systems (#760080) At the moment any messages for an encrypted file system aren't shown, only messages from the outer PartitionLUKS object are shown. Also in Win_GParted::activate_paste() the selected Partition object, possibly a derived PartitionLUKS, is cloned and the messages cleared. Therefore a set of accessor methods must be provided to query and modify partition messages. Messages will be stored in the Partition object to which they are added and retrieved from all. So in the case of a derived PartitionLUKS they will be retrieved from the messages vector of the PartitionLUKS object itself and the messages vector for the encrypted file system it contains. To replace code like this in GParted_Core: partition_temp->messages = messages; We might naturally provide a set_messages() method which assigns the messages vector and is used like this: partition_temp->set_messages( messages ); However on a PartitionLUKS object what should set_messages() do? By the name it will replace any existing messages in the PartitionLUKS object itself, but what should happen to the messages for the contained encrypted Partition object? Should they be cleared or left alone? Rather than implement set_messages() with unclear semantics implement append_messages(), which in the PartitionLUKS object case will clearly leave any messages for the contained encrypted Partition object alone. Append_messages() is then used to add messages as the Partition or PartitionLUKS objects when populating the data in GParted_Core. Bug 760080 - Implement read-only LUKS support
2015-12-31 09:32:08 -07:00
virtual bool have_messages() const;
virtual std::vector<Glib::ustring> get_messages() const;
virtual void clear_messages();
Display the label of encrypted file systems (#760080) LUKS headers don't provide any concept of label. Also there is already the method Partition::get_filesystem_label() for getting the *file system* label, so virtualise it and provide an appropriate implementation to get the label of an encrypted file system represented within a derived PartitionLUKS object. This causes the label to be displayed correctly in the main window. It also happens to display the encrypted file system label in the Information dialog for a LUKS formatted partition. However the whole Information dialog will be addressed differently in a following commit. Bug 760080 - Implement read-only LUKS support
2015-12-27 08:01:15 -07:00
Provide virtual Partition::get_filesystem_partition() method (#774818) 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
2016-09-06 00:33:26 -06:00
virtual const Partition & get_filesystem_partition() const;
Implement new UUID operation on encrypted file systems (#774818) 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
2016-09-06 09:03:05 -06:00
virtual Partition & get_filesystem_partition();
Provide virtual Partition::get_filesystem_partition() method (#774818) 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
2016-09-06 00:33:26 -06:00
Provide virtual Partition::get_filesystem_string() method (#774818) 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
2016-09-02 00:53:19 -06:00
virtual const Glib::ustring get_filesystem_string() const;
Add PartitionLUKS class and create objects (#760080) Absolute minimum implementation of a PartitionLUKS class which can be constructed, polymorphically copied and destroyed. Contains an "encrypted" member of type Partition to represent the encrypted file system within the LUKS format. Create PartitionLUKS objects instead of base Partition objects when a LUKS formatted partition is found. Only the base Partition object member values have been populated, and the "encrypted" member remains blank at this point. Bug 760080 - Implement read-only LUKS support
2015-11-11 14:12:39 -07:00
private:
Partition encrypted;
Make encrypted Partition objects look like whole disk device ones (#775932) Until now an encryption mapping has been modelled as a Partition object similar to a partition like this: .encrypted.device_path = "/dev/sdb1" .encrypted.path = "/dev/mapper/sdb1_crypt" .encrypted.whole_device = false .encrypted.sector_start = // start of the mapping in the partition .encrypted.sector_end = // end of the mapping in the partition However accessing device_path in the start to end sector range is not equivalent to accessing the partition path as it doesn't provide access to the encrypted data. Therefore existing functions which read and write partition data (GParted file system copying and signature erasure) via libparted using the device_path won't work and will in fact destroy the encrypted data. This could be coded around with an extra case in the device opening code, however it is not necessary. An encrypted block special device /dev/mapper/CRYPTNAME looks just like a whole disk device because it doesn't contain a partition and the file system it contains starts at sector 0 and goes to the end. Therefore model an encryption mapping in the same way a whole disk device is modelled as a Partition object like this: .encrypted.device_path = "/dev/mapper/sdb1_crypt" .encrypted.path = "/dev/mapper/sdb1_crypt" .encrypted.whole_device = true .encrypted.sector_start = 0 .encrypted.sector_end = // size of the encryption mapping - 1 Now GParted file system copy and erasure will just work without any change. Just need to additionally store the LUKS header size, which was previous stored in the sector_start, for use in the get_sectors_{used,unused,unallocated}() calculations. Bug 775932 - Refactor mostly applying of operations
2016-11-08 00:03:09 -07:00
Sector header_size; // Size of the LUKS header (everything up to the start of the mapping)
Add PartitionLUKS class and create objects (#760080) Absolute minimum implementation of a PartitionLUKS class which can be constructed, polymorphically copied and destroyed. Contains an "encrypted" member of type Partition to represent the encrypted file system within the LUKS format. Create PartitionLUKS objects instead of base Partition objects when a LUKS formatted partition is found. Only the base Partition object member values have been populated, and the "encrypted" member remains blank at this point. Bug 760080 - Implement read-only LUKS support
2015-11-11 14:12:39 -07:00
};
}//GParted
#endif /* GPARTED_PARTITIONLUKS_H */