Provide a udisksctl command to unlock and mount in one step

[ghost]

Please can udisksctl gain a command to unlock and mount a LUKS-encrypted drive in one step?

At the moment, there does not seem to be a way to do this.

A Bash script can be written to act as a wrapper, parsing the output of udisksctl unlock and passing the appropriate device name to the input of udisksctl mount, but this appears to go against the intentions of the authors/maintainers of udisksctl, who warn in the man page:

[This] program is not intended to be used by scripts or other programs - options/commands may change in incompatible ways in the future even in maintenance releases.

[vpodzime]

Please can udisksctl gain a command to unlock and mount a LUKS-encrypted drive in one step?

This is definitely a great idea. Thanks for the tip!

[CRCinAU]

I'm currently working through something similar to this where udisks goes nuts over the state of the drives / mounts when trying to auto-unlock drives with key-files...

I've documented my scripts for the moment here: https://www.crc.id.au/linux-and-usb-full-disk-encryption/

The problem is, there is no reliable way to use udisksctl to mount things - hence I have to rely on cryptsetup open to do the initial mapping to /dev/mapper/luks-*

At this point however, udisks2 doesn't seem to be able to realise that the encrypted volume is actually open - leading to it asking for a password input again. Going further, it seems strange that even when you create an fstab entry for /dev/mapper/luks-....... with the noauto,user options, you still get prompted for auth to mount the volume.

Dropping to a konsole session in my case will allow the user to perform mount /dev/mapper/luks-.....

As such, it may be multiple problems here that should be fixed - especially the fact we ignore the missing fstab entry - even if that devices appears...

[ghost]

@CRCinAU , nice scripts :)

You say, "something similar to this where udisks goes nuts ...". I realise that you have provided some explanation of this afterwards, but for ease of understanding, please could you document, as a terminal log, examples showing which commands, in which sequence, lead to which unexpected output? It would be ideal if you could format this in "Steps to reproduce", "Expected outcome" and "Actual outcome" sections, i.e. as a typical bug report.

This might help to clarify just how many distinct bugs or feature requests are lurking therein.

Thanks again :)

[CRCinAU]

I'm not exactly sure where the issues are at the moment - and I'm trying figure out exactly which problem belongs to which stack. I use Fedora 27 with KDE - and that has its own disk management stuff in the file manager Dolphin - which I believe uses udisks under the hood.

In a non-DE setup, the scripts work fine - and you just need to unmount / lock the partition before ripping out the USB drive - however that starts to change when udisks / a DE is thrown into the mix.

At this point in time, I know that following my guide (which is only missing a reload of the udev rules via udevadm control -R after adding the file - I'll fix that later) starts to give somewhat unpredictable results as far as the clicky-clicky interfaces.

Issues I've seen is the wrong status being shown, being prompted for 'unlock' passwords even after my script has unlocked the device, not being able to mount the BTRFS disk as a user, ignoring the fstab entry to allow user mounting to a non /media/something path.... and maybe more - but trying to narrow that down to a component basis is tricky - and I make need assistance there...

[CRCinAU]

So after more investigation - when I turn off the automounting within KDE, things improve a little - however Dolphin gets confused about the state of the media.

I'm not quite sure how the integration between udisksd and dolphin works - but it asks for a password to mount - then complains that the media is already mounted.

So, either udisksd doesn't send a dbus message in this scenario, or dolphin doesn't capture an update. I'm not sure how to tell these cases apart.

[rainemak]

Also from dbus API point of view would be nice to treat unlocking+mount as a "transaction". This way udisks could suppress polkit authentication from the mount operation and trust that unlocking was already authorized by the user.

Maybe "unlock" could have additional property in the option to indicate "auto-mount". This would of course have implicit assumption that unlocking and mounting would happen for the very same user.

Would this make sense? Should I report another task proposal about this?

[vpodzime]

Would this make sense? Should I report another task proposal about this?

Yes, it makes sense and I think it's an implicit part of the idea here. UDisks2 already does things like this -- e.g. loop-setup followed by mount.

[andradei]

This would be very convenient. It could be a flag on unlock --mount.