gparted/include/PartitionLUKS.h

72 lines
2.2 KiB
C
Raw Normal View History

/* 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
#include "Partition.h"
#include "Utils.h"
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>
namespace GParted
{
class PartitionLUKS : public Partition
{
public:
PartitionLUKS();
virtual ~PartitionLUKS();
virtual PartitionLUKS * clone() const;
Partition * clone_as_plain() 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 );
Partition & get_encrypted() { return encrypted; };
const Partition & get_encrypted() const { return encrypted; };
Sector get_header_size() const { return header_size; };
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;
virtual void resize( const Partition & new_size );
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();
virtual const Partition & get_filesystem_partition() const;
virtual Partition & get_filesystem_partition();
virtual const Glib::ustring get_filesystem_string() const;
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)
};
}//GParted
#endif /* GPARTED_PARTITIONLUKS_H */