On Wed, 2016-03-16 at 17:51 -0400, Nathaniel McCallum wrote: > On Wed, 2016-03-16 at 00:02 +0100, Bastien Nocera wrote: > > > > On Tue, 2016-03-15 at 16:59 -0400, Nathaniel McCallum wrote: > > > > > > > > > Sorry for the cross-post! However, I figured it was the best way > > > to > > > reach all the right people. > > > > > > I'm the author of the Tang[1] project. In a nutshell, Tang > > > provides > > > a > > > way to bind an encrypted disk to a network. We currently provide > > > automated unlocking of the root volume (via initramfs/systemd). > > > > > > However, one of our use cases is securing removable devices so > > > that > > > they can only be unlocked when the host computer is on a secure > > > network. I have looked a bit at the code for GVFS and udisks, but > > > it > > > wasn't immediately obvious to me the best way to proceed in > > > adding > > > support for this. So I'm here looking for suggestions. > > > > > > More or less, in order to automatically recover a disk's key we > > > need > > > read access to the LUKS header and network access to perform the > > > Tang > > > exchange. It would be my strong preference not to expose the > > > metadata > > > in the LUKS header to unpriviledge users. > > > > > > I attempted to test this by provisioning a USB key using Tang. > > > Upon > > > insertion, GNOME (properly) prompts for the password. If I > > > attempt > > > to > > > unlock the disk in the background during this operation, the > > > password > > > prompt is properly removed. However, the disk does not appear as > > > a > > > standard removable disk any more in Nautilus. > > > > > > Thoughts? Suggestions? > > Look at the output of "udisksctl dump". If your device shows up > > there, > > and depending on the value of the various properties it exposes > > (especially the hints), it might be a bug in gvfs' udisks-based > > volume > > monitor. > I was able to get things mostly working. But now I have the opposite > problem. Namely, the gnome prompt doesn't disappear. I can cancel it > and Nautilus seems to work fine. Should I file a bug against GVFS?
To reproduce the problem, create an encrypted usb key with the password "foo". Then, execute the following in a terminal and immediately insert the usb key (I am presuming here your usb key is on /dev/sdc): sleep 10 ; busctl call org.freedesktop.UDisks2 /org/freedesktop/UDisks2/block_devices/sdc org.freedesktop.UDisks2.Encrypted Unlock "sa{sv}" foo 0 When the key is inserted, the unlock dialogue pops up. After a few seconds, the command executes and unlocks the disk. However, the dialogue doesn't disappear. If you press cancel, and then view the disk in nautilus, it works; until you try to eject it, then it gives an error. IMHO, GVFS/Shell/Nautilus should be able to cope with an out of band process unlocking the inserted usb key. _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/devkit-devel