On 2020/11/05 03:29 AM, Janek Stolarek wrote:
I've been
using LUKS for a long time on several different distributions,
all with TDE installed. So this conversation has made me curious how TDE
having ‘support for unlocking / locking encrypted disks’ is different than
what is currently in use?
The way TDE 14.0.9 currently works (on my machine at
least) is that when I plug in an encrypted
external USB drive, Konqueror will ask for a password to unlock it, but upon entering
the
password it will report an error. So what I do is use a script that unlocks the LUKS
device and
mounts it*, at which point Konqueror again asks for a password to unlock the device
except now
that the device has been unlocked it mounts it correctly. I now wonder whether you know a
way to
bypass the need of unlocking/mounting the drive using a script?
Hi everyone,
I reply here to both Michael and Janek.
You can use LUKS disks in many ways.
1) you can unlock, mount, unmount and lock from CLI. This obviously works already in TDE
R14.0.x (in fact it has nothing
to do with TDE)
2) AFAIK, you can get use /etc/crypt, /etc/fstab and a password file to get the disk to
auto unlock and then mount. This
also works in R14.0.x
What does not work in R14.0.x is that if you have a LUKS disks and you don't use the
above methods, then you can't use
the disk. Konqueror will ask for a password but it will fail unlocking the disk.
In R14.1.0 you will be able to click on a LUKS disk, enter a password and unlock the disk.
Similarly you can lock it
back. So if you plug in the occasional USB LUKS drive or if you want to manually unlock
the disk (extra safety, you must
type the password each time, no stored password file), then you can do it from
Konqueror/KDesktop/KDCOP. There are more
changes under the hood, but this is the core feature.
Small note: in R14.1.0 an unlocked LUKS disk is a separate entity from its mountable disk.
Meaning if you have a
/dev/sdb1 LUKS disk, this will be lockable/unlockable, but not mountable. When unlocked,
there will be a separate device
(/dev/dm-0 in most cases) which is the actual mountable/unmountable drive. It may seems
cumbersome, but this is how the
OS handles the drives behind the scenes anyway. Moreover you may have more complex
structures with LVM or RAID and for
those cases it is necessary to handle the encrypted disk separately from its
"children" disks.
For those interested, you can try PTB inside a VM :-)
Hope this helps.
Cheers
Michele