Bug 2273

1) Which TDE version are you using?
2) How do you try to mount the device (CLI/double click on an icon,...)
3) Can you post a screenshot of the error?

Any other additional info would be useful for looking at the bug.

Created attachment 2408 [details]
Cannot mount LUKS volume TDE R14.0.0

Referring to the attachment:

#1 - Kubuntu 14.04.2 LTS, KDE 4.14.2, TDE R14.0.0 used

#2 - Volume on top (935.1GB), cannot be mounted. Volume on bottom (Data) can be accessed if logged into KDE first and mounted (mounting LUKS volume works here) and then fast switching to another user without unmounting LUKS volume first.

#3 - Sequence for mounting LUKS volume via desktop icon. Same sequence if trying to mount from Konqueror.

Thanks Michele for looking at this.

Thanks for the detail instructions and attachment. I asked very early to make sure we have proper information to work on (sometimes bugs sit there for months and then the original reporter has disappeared and can not provide any more info). This will definitely be useful when working on this bug.

R14.0.0 moved away from HAL and a lot of functionality was rewritten from scratch in tdehwlib.
This bug could be either one of the three following possibilities:
1) it is a bug the slip into the new code, in such case a fix in one of the R14.0.x maintenance releases would be possible
2) it is a missing functionality, in such case the fix will have to go for a minor release (such as R14.1.0).
3) looking at the code will reveal something else, in such case actions will be decided after finding the cause.

Ah, could you try one more thing.
Using only command line tools are you able to mount and access the device?

Yes. Using the following:

To Mount:

1. mkdir /mnt/mydir # directory to mount sdb1
2. sudo cryptseup luksOpen /dev/sdb1 crypt_sdb1 # open luks partition
3. [pass-phrase] # enter pass-phrase
4. sudo mount /dev/mapper/crypt_sdb1 /mnt/mydir # mount partition 


To Un-mount:

1. sudo umount /mnt/mydir
2. sudo cryptseup luksClose crypt_sdb1 # close luks partition

Upon entering step 2, the system detects the encrypted volume being opened and opens the normal GUIs to request a passphrase. I ignored these and continued with step 4. Volume mounted, albeit only with root access.

Correction: continued with step 3 to enter passphrase via cli and then mounted via step 4.

Thanks again, lot of useful info :-)
I made a note and I will try to have a look at the bug in the second half of January. Before that it is very unlikely I can do that.

I created a LUKS partition in a VM and did some testing. From CLI no problems to open and mount the partition, but from the GUI I am not able to complete the same thing. When I double click on the disk icon on the desktop, Konqueror opens and report an error, and at the same time another dialog appears in background and ask for the password to decrypt the device. After typing the password, the same dialog reappears asking again for the password. After the third time, I got an error message.
The error that I see is different from the screenshot attached by Sergeant, but in any case the decrypt and mount operation fails. My device is identified as an Unmounted Encrypted Hard Disk Volume instead of a Unmounted Encrypted Removable Media, perhaps that's the reason for the different error message.
Will do some more testing in the next few days.

Sergeant, can you check and confirm that if you type 
konqueror media:/sdb1
from Konsole (or Alt+F2), you get the same behavior?

Created attachment 2425 [details]
error screenshot

Using DCOP calls directly (from KDCOP) I can replicate the same error message when trying to decrypt the LUKS disk.

>R14.0.0 moved away from HAL and a lot of functionality was rewritten from >scratch in tdehwlib.
>This bug could be either one of the three following possibilities:
>1) it is a bug the slip into the new code, in such case a fix in one of the >R14.0.x maintenance releases would be possible
>2) it is a missing functionality, in such case the fix will have to go for a
>minor release (such as R14.1.0).
>3) looking at the code will reveal something else, in such case actions will be 
>decided after finding the cause.

The support for encryption/decryption is not in the tdehwlib at the moment. Being a new functionality, this will have to go in R14.1.0 and not in the R14.0.x maintenance releases, unless Tim or Slavek have different ideas.

Changed from Critical to Major since it is still possible to access the LUKS disk from Konqueror once the disk has been decrypted and mounted from CLI or Konsole.

Created attachment 2429 [details]
Encrypted Drive Tooltip

Created attachment 2430 [details]
Double-click on desktop icon

Created attachment 2431 [details]
Screenshots showing attempt to mount via Konqueror

(In reply to Michele Calgaro from comment #10)
> Sergeant, can you check and confirm that if you type 
> konqueror media:/sdb1
> from Konsole (or Alt+F2), you get the same behavior?

Michele,

Referring to my latest screenshots (2015.01.23), I can confirm that I get the same behaviour.

#1. Hover over Desktop icon to show drive type. Double-clicked on icon to open drive.

#2 & #3. Konqueror background initially white. Asked to enter password to decrypt.

#4. Konqueror background turns mottled grey and am asked to enter password again.

#5. Password not accepted and error dialog pops up.

#6. Invoke ALT+F2 and started Konqueror via command box. Same sequence of events.

>Referring to my latest screenshots (2015.01.23), I can confirm that I get the 
>same behaviour.
Thanks Sergeant, that's exactly what I see. As explained in comment 12, the fix will have to go to the next minor release since it seems to require quite a bit of new software. I also need to dwell into the tdehwlib code before I can do anything on it, since it is an area of TDE I haven't worked on yet. Surely it will be a good opportunity to learn something new :-)
In the meantime I hope the work-around of mounting/unmounting the disk from Konsole is not too much of an assle.

(In reply to Michele Calgaro from comment #18)
> >Referring to my latest screenshots (2015.01.23), I can confirm that I get the 
> >same behaviour.
> Thanks Sergeant, that's exactly what I see. As explained in comment 12, the
> fix will have to go to the next minor release since it seems to require
> quite a bit of new software. I also need to dwell into the tdehwlib code
> before I can do anything on it, since it is an area of TDE I haven't worked
> on yet. Surely it will be a good opportunity to learn something new :-)
> In the meantime I hope the work-around of mounting/unmounting the disk from
> Konsole is not too much of an assle.

Thanks Michele.

No, no problems using konsole to mount, easy to script too. However I'll need to do a little research as i've forgotten how to mount the device as my user. The work-around, as shown, mounts as root.

(In reply to Michele Calgaro from comment #12)
> >R14.0.0 moved away from HAL and a lot of functionality was rewritten from >scratch in tdehwlib.
> >This bug could be either one of the three following possibilities:
> >1) it is a bug the slip into the new code, in such case a fix in one of the >R14.0.x maintenance releases would be possible
> >2) it is a missing functionality, in such case the fix will have to go for a
> >minor release (such as R14.1.0).
> >3) looking at the code will reveal something else, in such case actions will be 
> >decided after finding the cause.
> 
> The support for encryption/decryption is not in the tdehwlib at the moment.
> Being a new functionality, this will have to go in R14.1.0 and not in the
> R14.0.x maintenance releases, unless Tim or Slavek have different ideas.

Actually basic support is present in tdehwlib (I just tested it a couple of weeks ago while extending the TDE hardware device manager).  However, it is quite possible that it is only partially working; for example I did not test as a different user and there was an odd quirk noted where the device would not unlock under certain circumstances.

Let me look into this further.

(In reply to Timothy Pearson from comment #20)
> (In reply to Michele Calgaro from comment #12)
> > >R14.0.0 moved away from HAL and a lot of functionality was rewritten from >scratch in tdehwlib.
> > >This bug could be either one of the three following possibilities:
> > >1) it is a bug the slip into the new code, in such case a fix in one of the >R14.0.x maintenance releases would be possible
> > >2) it is a missing functionality, in such case the fix will have to go for a
> > >minor release (such as R14.1.0).
> > >3) looking at the code will reveal something else, in such case actions will be 
> > >decided after finding the cause.
> > 
> > The support for encryption/decryption is not in the tdehwlib at the moment.
> > Being a new functionality, this will have to go in R14.1.0 and not in the
> > R14.0.x maintenance releases, unless Tim or Slavek have different ideas.
> 
> Actually basic support is present in tdehwlib (I just tested it a couple of
> weeks ago while extending the TDE hardware device manager).  However, it is
> quite possible that it is only partially working; for example I did not test
> as a different user and there was an odd quirk noted where the device would
> not unlock under certain circumstances.
> 
> Let me look into this further.

TDE uses pmount internally to actually unlock and mount the drive.  Does pmount work with the affected drive when used from the command line?

Thanks!

I am not sure, but this might be interesting http://bugs.pearsoncomputing.net/show_bug.cgi?id=2720

Just for info, back to work on this bug after sooooo long.
Sergeant, hope you are still around. I have questions more questions, I will post here.

Hi Michele, yes, I'm still here. I just attempted to replicate this bug and it still exists in R14.0.6 (using PClinuxOS Trinity 2019.04 distro). Drive accessible via CLI only.

Hi Sergeant, glad to see you are still here. Yes, support for LUKS is not yet completed, but I am now looking at it again :-)

Progress will be tracked on TGW
https://mirror.git.trinitydesktop.org/gitea/TDE/tde/issues/12

Hi Sergeant, 
if you add your non-removable disk to /etc/pmount.allow and you have pmount installed, the disk should be mountable from Konqueror. You may have issues umounting it though, it seems work is required on that area too. You can use pumount from command line to be sure to unmount the disk correctly.

(In reply to Michele Calgaro from comment #27)
> Hi Sergeant, 
> if you add your non-removable disk to /etc/pmount.allow and you have pmount
> installed, the disk should be mountable from Konqueror. You may have issues
> umounting it though, it seems work is required on that area too. You can use
> pumount from command line to be sure to unmount the disk correctly.

Hi Michele,

My /etc/pmount.allow file has the line /dev/sd[a-z][1-9][0-9] already there.

I then tried pmount as a regular user as follows

1. pmount /dev/sdc1 mydir                    # creates /media/mydir
2. asks for pass-phrase on the CLI           # enter pass-phrase
3. Dialog popup requests what to do next (shows decrypted volume name in title)
4. Click 'Open in New Window'                # Konqueror opens at /media/dm-0
5. Dialog appears stating /dev/dm-0 is encrypted and requests password

At this point it doesn't matter what I put in (passphrase, root or user password) I cannot access the drive and I'm not asked again for the correct response despite  again clicking on the drive folder in Konqueror. 

However, opening Konqueror as root, allows access to the drive.

pumount unmounts the drive correctly.

Hi Sergeant,
I did some tests some weeks ago and I think to remember that it worked fine as long as /etc/pmount.allow was correctly setup. What I did was to open the disk from either Konqueror or a KDesktop icon, then typed the password and the disk opened up ok (I did not use pmount from CLI). I can try again if you want, but I need to rebuild tdelibs and tdebase to do that since I am currently using a modified version for testing my work.
Just for info, work on this bug is progressing and you can catch up with it using the link in comment 26.
The scope of the bug is actually wider than what initially mentioned here. We need:
- udisks2/udisks/udevil/pmount/hal support for luks (and in general other) disks
- correctly handle LVM on luks
- a polkit authentication agent
- several fixup/improvements in tdehw/mediamanager to correctly handle the unlock/mount/unmount/lock cycle for a device
I already have a working proof-of-concept solution that uses udisks2 to handle luks disks successfully as root using konqueror or kdesktop icons, so it is just a matter of keep developing the required parts and we will get there :-)

As an updated on this, after so long LUKS support has been added to the master branch (R14.1.0-dev).
Work is not finished and there is more to be done before the bug can be closed, but on a linux system using tdehw and udisks2, LUKS drives can now be locked/unlocked from Konqueror/KDesktop/DCOP successfully.

Finally after so long I can close this bug report. GUI LUKS support has been added in R14.1.0-dev.