1

Topic: Please add luks support

I really like GParted, but the one thing that is lacking and sorely needed is the ability to deal with encrypted partitions. Specifically, I really would like to be able to use it to resize some LUKS encrypted partitions. However, to date there is no support in GParted for doing so. In fact, there appears to be no GUI tool available for doing so.

Such an addition would be greatly appreciated.

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

2

Re: Please add luks support

Thanks for your interest in GParted.  There is a bug enhancement request for this feature.

Bug 171144 - supporting resizing of encrypted partition

Do you know what steps or commands to use from a terminal to resize LUKS?  If so then if would help if you could post these commands.

3

Re: Please add luks support

gedakc wrote:

Thanks for your interest in GParted.  There is a bug enhancement request for this feature.

Bug 171144 - supporting resizing of encrypted partition

Do you know what steps or commands to use from a terminal to resize LUKS?  If so then if would help if you could post these commands.

Unfortunately, I do not. That is why I was requesting support in GParted.

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

4

Re: Please add luks support

Unfortunately I too am unaware of any existing commands to resize LUKS.  If anyone does learn of such commands then we would like to hear about these.

5 (edited by StephenH 2011-10-13 19:40:14)

Re: Please add luks support

There are some pages addressing this. I do not know if it is the correct information needed, but it is the closest thing I have found to detailed guides on resizing LUKS encrypted partitons:

http://ubuntuforums.org/showthread.php?p=4530641

This is another page addressing resizing:

http://www.debian-administration.org/ar … ilesystems

This one is Apple-centric, but may provide some additional information:

http://markferry.net/pmwiki/pmwiki.php? … ResizeLUKS

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

6

Re: Please add luks support

Thank you for the extra information.

These examples appear to use LVM.  Support for LVM has not yet been added to GParted either and there is an open bug request.
Bug 160787 - lvm support

7

Re: Please add luks support

This page seems to indicate that if GParted can be made LUKS aware, then it would be workable.

https://code.google.com/p/cryptsetup/wi … dQuestions

Particularly this section:

    Can I resize a dm-crypt or LUKS partition?

    Yes, you can, as neither dm-crypt nor LUKS stores partition size. Whether you should is a different question. Personally I recommend backup, recreation of the encrypted partition with new size, recreation of the filesystem and restore. This gets around the tricky business of resizing the filesystem. Resizing a dm-crypt or LUKS container does not resize the filesystem in it. The backup is really non-optional here, as a lot can go wrong, resulting in partial or complete data loss. Using something like gparted to resize an encrypted partition is slow, but typicaly works. This will not change the size of the filesystem hidden under the encryption though.

    You also need to be aware of size-based limitations. The one currently relevant is that aes-xts-plain should not be used for encrypted container sizes larger than 2TiB. Use aes-xts-plain64 for that.

If the tools in cryptsetup can handle the LUKS part, then it would seem to be easy to let the current capabilities of GParted handle resizing the filesystem.

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

8

Re: Please add luks support

Thanks again for the extra info.

GParted does detect crypt-luks partitions as stated in the features page.  That is all that it does at present though.

9

Re: Please add luks support

I have entered an issue on the cryptsetup page:

https://code.google.com/p/cryptsetup/is … ail?id=114

I am not capable of providing the information needed to add this capability, but perhaps the cryptsetup developers can provide it. It would be very beneficial if GParted could do more than just detect crypt-luks partitions.

Respectfully,

Stephen

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

10

Re: Please add luks support

Time is what is needed most.  If you have time to research the problem and the code and develop a patch then that would help immensely.

11

Re: Please add luks support

Unfortunately, there are two things I lack to do so. First is knowledge of how to develop a patch. I have studied Hebrew and Greek, but coding a patch would require learning yet another language. That leads to the second thing. I do not have the time because mid-term exams and papers are coming due. Time will eventually not be so critical, but knowledge of how to write computer code is not so easy to overcome.  sad  I consider myself an advanced user, not a developer. The last time I tried to write anything it was back when I had a Commodore 64. I made a utility to do some financial calculations in Commodore Basic and then did so in COMAL. That was about 25 years ago. I never did get a grasp of PC computer languages.

Perhaps the cryptsetup developers can be of more assistance there. Hopefully, one of them will contact you. I posted a link to this thread in a feature-request there.

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

12

Re: Please add luks support

I received this response about cryptsetup:

Comment #1 on issue 114 by gmazyl...@gmail.com: Request:  coordinate with GParted to enable resizing of encrypted partitions
http://code.google.com/p/cryptsetup/iss … ail?id=114

So they should ask. Resizing of active mapping is just one call of libcryptsetup, see action_resize() in cryptsetup.c

Resize underlying device, call crypt_resize() and you are done. The problem is that it is sometimes impossible to properly resize kernel partition if it is in use.

For activating device there is nothing to do - cryptsetup will read new partition size. No size stored on disk.

Does this mean that if the underlying space is allocated by GParted during a resize operation, then the cryptsetup resizing is trivial? If so then (If I understand correctly) would the encrypted partition then need to be opened so that the filesystem contained in it can be resized? If so, then how would GParted then go about prompting for the key phrase to unlock it? Would that necessarily entail mounting the filesystem, or would the filesystem remain unmounted but just decrypted so that the resize of the filesystem could then take place? These are things best coordinated directly rather than through an intermediary as I may or may not understand the situation completely enough to ask the right questions.

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

13

Re: Please add luks support

StephenH wrote:

Does this mean that if the underlying space is allocated by GParted during a resize operation, then the cryptsetup resizing is trivial? If so then (If I understand correctly) would the encrypted partition then need to be opened so that the filesystem contained in it can be resized?  If so, then how would GParted then go about prompting for the key phrase to unlock it?  Would that necessarily entail mounting the filesystem, or would the filesystem remain unmounted but just decrypted so that the resize of the filesystem could then take place?

These are all good questions.  For GParted to resize a partition and successfully inform the kernel of the change the partition must not be in use.  This means that it cannot be active at all (i.e., mounted file system, swap space in use, active part of logical volume manager, etc.)  A way to determine if it is active or not is needed.  Also needed is a way to deactivate the partition if it is active.

Some file systems must be mounted when resizing, such as btrfs, jfs, and xfs.  Most others must not be mounted when resizing.

Perhaps you could try to learn the command line steps needed to perform these actions.  Then we can investigate ways to implement these in gparted.

14

Re: Please add luks support

gedakc wrote:
StephenH wrote:

Does this mean that if the underlying space is allocated by GParted during a resize operation, then the cryptsetup resizing is trivial? If so then (If I understand correctly) would the encrypted partition then need to be opened so that the filesystem contained in it can be resized?  If so, then how would GParted then go about prompting for the key phrase to unlock it?  Would that necessarily entail mounting the filesystem, or would the filesystem remain unmounted but just decrypted so that the resize of the filesystem could then take place?

These are all good questions.  For GParted to resize a partition and successfully inform the kernel of the change the partition must not be in use.  This means that it cannot be active at all (i.e., mounted file system, swap space in use, active part of logical volume manager, etc.)  A way to determine if it is active or not is needed.  Also needed is a way to deactivate the partition if it is active.

Some file systems must be mounted when resizing, such as btrfs, jfs, and xfs.  Most others must not be mounted when resizing.

Perhaps you could try to learn the command line steps needed to perform these actions.  Then we can investigate ways to implement these in gparted.

The information I previously posted is how cryptsetup resizes the encrypted partition. However, in order to do this, the underlying device's space allocation must be changed. This is not something that cryptsetup can accomplish. Can GParted resize the space allocated (and in the process, move the existing encrypted information to the new location if the starting point changes such as adding space on the front? If so then the commands detailed in post # 12 would seem to be sufficient to accomplish the task. The next thing would be to give GParted a means of unlocking the encryption so that the filesystem can then be expanded to fill the new space.

For example, expanding by adding new space on the end:

Before:  |---------------------------------------|
After:     |--------------------------------------------------------------------------|

expand partition's allocation, call crypt-resize(), unlock encryption, expand filesystem.

Move and add:

Before:                        |---------------------------------------|
After:    |--------------------------------------------------------------|

Expand partition's allocation, copy bit-by-bit the information to the front of the new space, call crypt-resize(), unlock encryption, expand filesystem.

I am posting a request for command line examples of how to do this on the cryptsetup page. It would be simpler if you would go there yourself and ask as the developer there who replied seemed more than willing to assist. A direct communication between GParted developers and cryptsetup developers would likely lead to better results than me trying to work my way through the mechanics of this action.

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

15

Re: Please add luks support

StephenH wrote:

It would be simpler if you would go there yourself and ask as the developer there who replied seemed more than willing to assist. A direct communication between GParted developers and cryptsetup developers would likely lead to better results than me trying to work my way through the mechanics of this action.

It comes down to free time.  I have many other tasks that I am working on so this one is low priority for me.  That is why I suggest that someone, such as yourself, perform as much of the background work as possible.

16

Re: Please add luks support

gedakc wrote:

It comes down to free time.  I have many other tasks that I am working on so this one is low priority for me.  That is why I suggest that someone, such as yourself, perform as much of the background work as possible.

Unfortunately, my time is also quite limited. I am a seminary student, and the coursework which I must complete does not allow me the time to do this. So it is something that, no matter how desirable it would be to have this working, must wait until one of us has the time available to work on it.  Thank you for your taking the time to discuss this with me. Even if it is (so to speak) on the back burner, it is nice to know it is at least on the stove. smile

StephenH
"We must understand the reality that just because our culture claims certain things are true it does not mean they are!" --M. Liederbach
[url]http://pilgrim-wanderings.blogspot.com[/url]

17

Re: Please add luks support

Gparted support for resizing luks (and also LVM) partitions is very important not just for gparted but for GNU/Linux as a whole. I personally have installed about 6 distributions with luks encrypted partitions for non-technical people recently, and if any of them need to dual boot or change their disk setup in future they won't be able to - a a full format and reinstall will be required.

Luks is becoming the standard system used by distro installers and as the years roll by a means of working with such partitions graphically becomes more and more urgent. Please consider this when setting priorities for gparted in future.

18 (edited by cosmos72 2012-03-06 04:42:42)

Re: Please add luks support

I have performed this task manually, and it's really simple. Basically, there is _almost_ no surprise - but please read the WARNING at the end.

Provided that the encrypted device is not in use, to enlarge it you need:
1) enlarge the underlying partition. Gparted can already do this
2) activate the encrypted device with "cryptsetup luksOpen <path-to-underlying-partition> <encrypted-device-name>". For example, it could be "cryptsetup luksOpen /dev/sda2 my_secure_device"
    Obviously, you may need to enter your secret password to perform this step!
3) the file-system inside /dev/mapper/<encrypted-device-name> is now accessible _unencrypted_, so it can be enlarged with _normal_ tools. Gparted can already do this.

The key point is the one cited by StephenH: "For activating device there is nothing to do - cryptsetup will read new partition size. No size stored on disk."
I can confirm this from personal experience, i.e. I tried and it works: there is no need to tell LUKS that the underlying partition changed size. You would need to call crypt_resize() or "cryptsetup resize ..." only if the encrypted device was already active, but in the scenario depicted above this cannot happen.

To shrink a filesystem, you must (quite) obviously perform the opposite operations in inverse order:

0) make sure the encrypted device is active (you can use step 2 above if not)
1) the file-system inside /dev/mapper/<encrypted-device-name> is now accessible _unencrypted_, so it can be shrank  with _normal_ tools. Gparted can already do this.
2) deactivate the encrypted device with "cryptsetup luksClose <encrypted-device-name>". For example, it could be "cryptsetup luksClose my_secure_device". Your secret password is not required here.
3) shrink  the underlying partition. Gparted can already do this.

WARNING: LUKS encrypted devices start with a LUKS header that takes some space - the exact amount can change, and running "cryptsetup luksDump <path-to-underlying-partition>" will report it, among other information, after the label "Payload offset:" (encrypted device does not need to be active to run this command). In some examples I tried, the "Payload offset" varied between 2056 and 4096, and it appears to be expressed in sectors (i.e. the unit is 512 bytes). I have no idea which unit is used if you have a disk whose sectors are not 512 bytes (it happens with newer disks, see "advanced disk format").

This "Payload offset" is not a problem when enlarging: file-system enlarging tools will check for available space in encrypted device - even without knowing it's encrypted.
Instead, while shrinking it means that the used space inside the underlying partition is _larger_ than the file-system length, and the underlying partition minimum size is file-system length _plus_ the "Payload offset" (be careful when adding them, they could be in different units).

19

Re: Please add luks support

Thank you cosmos72 for the additional information.  Currently I am working to get GParted to link and compile with gtkmm-3.0, which is a major task.

If you have time to work on this enhancement, please follow up in the following bug report so that we can properly keep track of your work.

Bug 171144 - supporting resizing of encrypted partition

20

Re: Please add luks support

Hello Curtis,

you kindly accepted my offer to integrate my program fstransform as a gparted plugin, so I am giving priority to that task for obviously personal reasons.

I will be honest and direct: my spare time is quite limited, so I do not know if/when I can have time to work also on this second task.

Thanks for your kind and quick reply,

Massimiliano

21

Re: Please add luks support

No worries Massimiliano.  As volunteers, such enhancements must wait until we have sufficient free time and inclination to work on these.  :-)

22 (edited by mgehre 2012-08-31 10:56:10)

Re: Please add luks support

Hi,

I have written a patch to add initial luks support. Please find it here:
http://pastebin.com/2NzWJCp2

I'm not sure how to proceed with the development. Should I open a bug report
for this? (I didn't find a matching one)

I'm looking forward to your comments.
Especially, I was not sure about using libcryptsetup vs. calling cryptsetup binary.
I find the first options more elegant, but it seems that the second option is used more often
throughout the code.

Best wishes
Matthias

Edit: updated url

23 (edited by gedakc 2012-09-01 03:10:02)

Re: Please add luks support

Hi Matthias.  Thank you for developing an enhancement patch.

mgehre wrote:

I have written a patch to add initial luks support. <snip>

I'm not sure how to proceed with the development. Should I open a bug report
for this? (I didn't find a matching one)

This is an existing bug report for crypt luks support.
Bug 627701 - option to encrypt new partitions (using LUKS)

Please post your patch and questions there so that we can track the enhancement in one location.   If your patch does more that the title implies, then we can change the title.

The GParted web site contains some basic information on the development page.

Regards,
Curtis

EDIT:  Added development web page link.