Add new item to the partition menu to allow the user to open and close
the LUKS mapping. However for now the menu item is always disabled and
there is no implementation behind it to actually open or close the LUKS
mapping. Fragment of the partition menu is now:
...
Format to >
-----------------
Open Encryption <- New menu item
Mount
-----------------
Name Partition
...
Has to be two separate menu items to clearly represent to the user that
LUKS mappings and file system mounting are two separate busy states.
And also in the case of an open but unmounted file system to offer both
actions; close encryption and mount file system.
The text of the menu item automatically changes similarly to how it does
for the Mount/Unmount, Swapon/Swapoff, Activate/Deactivate item
depending on the state of the LUKS mapping. For open LUKS mappings it
will show "Close Encryption" and for all other cases (closed LUKS
mapping or partition is not encrypted) "Open Encryption". Again similar
to how the default of "Mount" is shown for unallocated and unknown
partitions.
Bug 795617 - Implement opening and closing of LUKS mappings
In preparation for adding the ability to toggle the encryption busy
state (open/close the encryption volume), rename existing members to
reflect that they are related to changing the file system state. (Swap
and LVM2 Physical Volumes are handled as file systems by GParted).
class Win_GParted renaming:
MENU_TOGGLE_BUSY -> MENU_TOGGLE_FS_BUSY
allow_toggle_busy_state() -> allow_toggle_fs_busy_state()
toggle_busy_state() -> toggle_fs_busy_state()
check_toggle_busy_allowed() -> check_toggle_fs_busy_allowed()
Bug 795617 - Implement opening and closing of LUKS mappings
Replace echoing "dm" into jfs_debugfs via a shell command to directly
writing "dm" to the input of the jfs_debug command. One less use of the
shell.
Bug 795617 - Implement opening and closing of LUKS mappings
As discussed in "LUKS password handling, threats and preventative
measures" [1] GParted must be able to pass LUKS passphrases to
cryptsetup via standard input to avoid having to write passwords to the
file system and deal with additional security requirements. Therefore
add a way to write input into created child processes. For small
amounts of input, writing up to the pipe buffer capacity won't block
[2]. This is 64K on versions of Linux in any currently supported
distributions.
[1] LUKS password handling, threats and preventative measures
https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56
GParted must not become a password manage so it must never save
LUKS passwords to disk across separate invocations of GParted.
...
GParted should avoid writing a temporary file containing the LUKS
password as it introduces extra complexity with trying to safely
handle and erase file content. Instead GParted must
programmatically pass the LUKS password via standard input to the
cryptsetup command.
[2] pipe(7) manual page:
Pipe capacity
A pipe has a limited capacity. If the pipe is full, then a
write(2) will block or fail, depending on whether the O_NONBLOCK
flag is set (see below). ...
In Linux versions before 2.6.11, the capacity of a pipe was the
same as the system page size (e.g., 4096 bytes on i386). Since
Linux 2.6.11, the pipe capacity is 65536 bytes.
Bug 795617 - Implement opening and closing of LUKS mappings
Use private access into the PasswordRAMStore class to directly obtain
the address of the locked memory, rather than inferring it from the
address of the first stored password. This simplifies
PasswordRAMStoreTest::SetUpTestCase() and avoids encoding most of the
implementation knowledge that the first password will be stored at the
start of the protected memory.
Bug 795617 - Implement opening and closing of LUKS mappings
Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the
same method as used in the PasswordRAMStore destructor.
Bug 795617 - Implement opening and closing of LUKS mappings
Move zeroing of the locked memory into separate PWStore::erase_all()
private method. Then use this in the PWStore destructor. This is so
that zeroing of all passwords can be unit tested independently of
destructing the singleton PWStore object.
Bug 795617 - Implement opening and closing of LUKS mappings
As noted in comments:
1) This is white box testing because it uses implementation knowledge
to look through the API to the internals of the password store.
2) It is not currently possible to test that the passwords are zeroed
when the store is destroyed.
However zeroing of memory is being tested when individual passwords
are erased.
Bug 795617 - Implement opening and closing of LUKS mappings
Application level requirements for secure password management were set
out in "LUKS password handling, threats and preventative measures" [1].
The requirements are:
1) Passwords are stored in RAM and are not allowed to be paged to swap.
(However hibernating with GParted still running will write all of RAM
to swap).
2) Passwords are wiped from RAM when no longer needed. When each
password is no longer needed and when GParted closes.
3) Passwords are referenced by unique key. Recommend using LUKS UUIDs
as the unique key.
(Each LUKS password should only ever need to be entered once for each
execution of GParted. Therefore the passwords can't be stored in any
of the existing data structures such as Partitions or LUKS_Info cache
because all of these are cleared and reloaded on each device
refresh).
There seems to be two possible implementation methods: use an existing
library to provide secure memory handling, or write our own.
Libgcrypt [2] and libsodium [3] cryptographic libraries both provide
secure memory handling. (Secure memory is quite simple really, some
virtual memory locked into RAM which is zeroed when no longer needed).
Linking to an encryption library just to provide secure memory seems
like using a sledge hammer to crack a nut. Also because of requirement
(3) above a module is needed to "own" the pointers to the passwords in
the secure memory. Managing the secure memory ourselves is probably no
more code that that needed to interface to libgcrypt. Therefore handle
the secure memory ourselves.
So far the module is only compiled. It is not used anywhere in GParted.
[1] LUKS password handling, threats and preventative measures
https://bugzilla.gnome.org/show_bug.cgi?id=627701#c56
[2] libgcrypt general purpose cryptographic library, as used in GNU
Privacy Guard
https://gnupg.org/related_software/libgcrypt/
[3] libsodium crypto library
https://download.libsodium.org/doc/
Bug 795617 - Implement opening and closing of LUKS mappings
Found that older but still supported distributions Debian 8 and
Ubuntu 14.04 LTS don't have directory /dev/disk/by-path/. This is used
by the BlockSpecial unit test as a source of a symbolic link to a block
special device.
This causes the unit test to fail like this:
$ cd tests
$ ./test_BlockSpecial
...
[ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches
test_BlockSpecial.cc:137: Failure
Failed
get_link_name(): Failed to open directory '/dev/disk/by-path'
test_BlockSpecial.cc:168: Failure
Failed
follow_link_name(): Failed to resolve symbolic link ''
test_BlockSpecial.cc:255: Failure
Expected: (lnk.m_name.c_str()) != (bs.m_name.c_str()), actual: "" vs ""
[ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms)
...
[ FAILED ] 1 test, listed below:
[ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches
1 FAILED TEST
Which in turn causes make check and make distcheck to fail.
Use directory /dev/disk/by-id/ instead as it always exists.
Increase the minimum required version of gtkmm to 2.16.0, thus allowing
removal of HAVE_GTK_SHOW_URI autoconf definition and associated fallback
code.
Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required
versions to glibmm 2.14.0 and gtkmm 2.16.0
Increase the minimum required version of gtkmm to 2.11.1, thus allowing
removal of:
* HAVE_SET_DEFAULT_ICON_NAME autoconf definition and associated
optional code.
* INSTALL_PIXMAPS_DIR automake conditional and associated make
instructions.
This is reversing these 3 commits, except for the higher minimum gtkmm
version:
1) a042107883
Only use Gtk::Window::set_default_icon_name method when available (#695279)
2) b09d6035cd
Add fallback method for specifying GParted icon (#695279)
3) d6baac2546
Only install fallback icon when required (#695279)
Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required
versions to glibmm 2.14.0 and gtkmm 2.16.0
Increase the minimum required version of glibmm to 2.14.0, thus allowing
removal of the HAVE_GLIB_REGEX autoconf definition and associated
conditional code. This is reversing commit, except for the new glibmm
minimum check:
456932846b
Implement fallback if Glib::Regex class is missing (#695279)
Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required
versions to glibmm 2.14.0 and gtkmm 2.16.0
E2fsprogs 1.41.0 (from 10 July 2008) first included ext4 support [1].
As RHEL / CentOS 6 is now the oldest supported distribution, and that
includes e2fsprogs 1.41.12 (from 22 August 2009) [2] all the e2fs
programs support ext4 so it is no longer necessary to also depend on
finding mkfs.ext4 before enabling each supported capability for ext4.
This makes the ext2::get_filesystem_support() look like all the others
in which each supported capability only depends on the presence of the
relevant file system specific command.
[1] Release notes for the e2fsprogs package / E2fsprogs 1.41.0
http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.41.0
[2] pkgs.org > CentOS 6 > CentOS x86_64 > e2fsprogs
https://centos.pkgs.org/6/centos-x86_64/e2fsprogs-1.41.12-23.el6.x86_64.rpm.html
Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required
versions to glibmm 2.14.0 and gtkmm 2.16.0
PATCHSET OVERVIEW:
As of 31 March 2017 RHEL / CentOS 5 reached the end of their support
[1][2]. Therefore remove code which supports them. This makes RHEL /
CentOS 6 the oldest supported distribution. So the minimum required
versions of glibmm and gtkmm can be increased dropping some autoconf
checks and conditional code supporting older versions of these
libraries. This will undo the bulk of these these previous bug fixes:
* GParted 0.21.0
Bug 738706 - Add support for ext4 on RHEL/CentOS 5.x
* GParted 0.16.1
Bug 695279 - Fix GParted doesn't compile on RHEL / CentOS 5.9
[1] Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates
[2] Subject: CentOS Linux 5 EOL
https://lists.centos.org/pipermail/centos-announce/2017-April/022350.html
THIS PATCH:
Remove checks for e4fsprogs commands, removing support for ext4 on
RHEL / CentOS 5.x. This is reverting earlier commit:
f672f68863
Check for e4fsprogs commands for ext4 support on RHEL/CentOS 5.x (#738706)
Mkfs_cmd member variable is being kept as a convenience so that it is
created once rather than on each use. Also note that as it is a
Glib::ustring type object, it's constructor will be called which will
initialise it to the empty string so it doesn't need initialising to the
empty string in the initialiser list of the ext2() constructor itself.
Bug 794253 - Desupport RHEL / CentOS 5 and raise minimum required
versions to glibmm 2.14.0 and gtkmm 2.16.0
Use of USE_GNOME2_MACROS is deprecated in GNOME 3 and produced this
warning:
$ ./autogen.sh
/usr/bin/gnome-autogen.sh
...
***Warning*** USE_GNOME2_MACROS is deprecated, you may remove it from autogen.sh
...
It's use appears to have been removed first from GNOME 2.8 with this
commit from 2004:
https://git.gnome.org/browse/gnome-common/commit/?id=ea9e85851445efa0135c3f8d08c3d1ea53760d91
delete some files that were unused after the reorganisation
The oldest supported distribution is RHEL / CentOS 6 which is using
gnome-common-2.28.0 from 2009. Therefore unconditionally remove the
USE_GNOME2_MACROS setting.
Also confirmed that it makes no difference by running ./autogen.sh with
and without USE_GNOME2_MACROS being set. The produced GParted build
trees were the same. Therefore the release and executable can't be
affected.
Scrollkeeper and the associated OMF catalog files are used by the
GNOME 2 version of yelp to display the GParted help manual. To see how
this works try the following command:
yelp ghelp:gparted
GNOME version 3 and higher yelp do not require scrollkeeper or the OMF
catalog files to properly display the GParted help manual. And in fact
GNOME 3 deprecated the GNOME 2 method of building and installing GNOME
help documents altogether; including use of GNOME_DOC_INIT autoconf
macro, the gnome-doc-utils package and use of scrollkeeper.
[GNOME 3] GNOME Goal: Port To New Documentation Infrastructure
https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure
Further, the next release of Debian, Debian 10 (Buster), will be
removing the scrollkeeper / rarian package.
rarian: Don't release with Buster
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885657
GParted is still a GNOME 2 app using GNOME 2 documentation build system
using autoconf GNOME_DOC_INIT macro.
[GNOME 2] Migrating your documentation to gnome-doc-utils
https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo
This is needed to build GParted documentation on still supported GNOME 2
distributions RHEL / CentOS 6. So avoid requiring deprecated
scrollkeeper on GNOME 3 by automatically disabling scrollkeeper database
updates when the scrollkeeper-update command is not available.
Executable | Configure option used | Use scrollkeeper
scrollkeeper-update | on command line | when building help
exists? | | for GParted?
--------------------+------------------------+-------------------
Yes | <none> | Yes
Yes | --enable-scrollkeeper | Yes
Yes | --disable-scrollkeeper | No
| |
No | <any> | No
Note that because GParted is still using the GNOME 2 documentation build
system it still builds and installs OMF files. It is just that they are
not required with GNOME 3 yelp and this commit automatically disables
updating the scrollkeeper database when the scrollkeeper-update command
is not available.
Bug 743318 - configure script missing check for scrollkeeper dependency
Struct FS and struct FS_Limits are strongly related to the FileSystem
class, both being return values from members and associated with storing
file system attributes. Move their definitions from Utils.h into
FileSystem.h.
There are too many different types of things named "filesystem" in the
GParted code with the potential to cause confusion. Namely:
std::vector<FS> FILESYSTEMS
Vector of file system capabilities.
class FileSystem Base class interfacing to file system
specific executables for querying and
modification.
enum FILESYSTEM Symbolic constants representing each file
system type.
Many recent written or re-written functions already used a variable
named fstype. Rename enum FILESYSTEM to enum FSType to clearly
distinguish it from the other things with very similar names. Only
changing the name of the enumeration, not the name of variables of that
type too because that is a lot more lines of code and those can be
changed when the relevant code is re-written.
Try to format an existing partition with a file system which doesn't
fit. The error dialog reporting the partition as too small or too large
always claimed the file system was encrypted, whether it was or not.
For example trying to format a 128 MiB partition as btrfs produces this
error dialog:
(-) Cannot format this file system to [Encrypted] btrfs
A [Encrypted] btrfs file system requires
a partition of at least 256.00 MiB.
[ OK ]
This commit:
88136c96d7
Extend functions generating encrypted file system string (#774818)
just completely missed handling the case for non-encrypted file systems
in Utils::get_filesystem_string(). Add the missed code.
There are multiple repetitions of the same code getting a FileSystem
object, checking for NULL and then calling the file system specific
get_filesystem_limits(). Extract that into a common function.
GParted_Core::get_filesystem_limits() can't use the file system from the
passed Partition object because that is the current file system which
will be different from the intended file system for new and format
operations. So would look up the wrong derived FileSystem specific
object and call the wrong get_filesystem_limits(). Hence still needing
fstype as a separate parameter to pass the intended file system.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
UDF file system minimum and maximum size limits are defined in terms of
numbers of file system blocks. So when resizing an existing file system
compute the byte size limits from the existing UDF file system's block
size. Alternatively when creating a new UDF file system use the
device's sector size as the multiplier instead.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
As described in the previous commit, this is so that file system
specific implementations can dynamically determine size limits based on
Partition object attributes: such as the device sector size and the file
system block size. (Assuming set_used_sectors() sets
partition.fs_block_size for the type of file system in question).
Bug 787204 - Minimum and maximum size of the UDF partition/disk
Background information about UDF is that when creating a file system
it's block size must match the underlying device's sector size. For
optical media like CDs and DVDs that is 2K. For hard drives that is
usually 512 bytes or 4K. However if a UDF file system has been copied
from a device with a different sector size the UDF block size won't
match the sector size. Linux will happily mount such UDF file system.
Therefore the derived udf::get_filesystem_limits() will need access to
the file system block size when determining the size limits of an
existing UDF file system being resized and use the device sector size
when a new UDF file system is being created. All this can be queried
from an appropriate Partition object passed to get_filesystem_limits().
All the calls to get_filesystem_limits() have an appropriate Partition
object available already, except in Win_GParted::activate_reformat()
when composing a format operation. Or more correctly
activate_reformat() constructs temp_ptn, a suitable Partition object,
including with fs_block_size member defaulting to -1 indicating not a
resize, but not until after the file system size limits had been checked
and get_filesystem_limits() called.
Therefore reorder the code in activate_paste() so that the file system
size limits are checked after the wanted Partition object has been
created. No functional change with this commit.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
All the code has been switched to call get_filesystem_limits() and use
struct FS_Limits. Remove struct FS members .MIN & .MAX.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
Change Dialog_Partition_New to use a fs_limits rather than struct FS
and .MIN and .MAX. No passing of struct FS_Limits required. Just use
the FILESYSTEMS vector of struct FS to provide the file system type and
look up it's size limits each time the selection changes.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
Refactor Win_GParted::activate_resize() to query the file system size
limits using the new get_filesystem_limits() method and pass those
limits into the dialog class as struct FS_Limits.
Bug 787204 - Minimum and maximum size of the UDF partition/disk
Mike Fleetwood