Robust non-root encrypt mount without root password?

[Crumbs516]

Is there a robust way for local users to be allowed permission to mount encrypted non-usb partitions under systemd based Jessie?

As outlined in http://forums.debian.net/viewtopic.php?f=10&t=132749 I edited /etc/crypttab to include the udev information which worked until a few boots later. I'm not sure what triggered the change but the udev path for the drive changed. I'm guessing it is because I turned on the scanner which is connected via usb.

What causes changes in the pci device tree? Anyone have a good reference?

How to get information about the drive:

Code: Select all

udevadm info -q path -n /dev/sdb

Here is what I was doing before based on the pci tree...

Code: Select all

   # ref: https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/apcs04s06.html
$ vim /etc/crypttab

   # to allow non-root users to mount encrypted partitions on a specific hard drive
   # pass output of following command to DEVPATH argument where sdb is the drive with the encrypted partition
   #   $ udevadm info -q path -n /dev/sdb
   #   /devices/pci0000:00/0000:00:08.1/ata4/host3/target3:0:0/3:0:0:0/block/sdb
   # reduce to host3/* means all devices on that sata port are mountable by non-root users

   DEVPATH=="/devices/pci0000:00/0000:00:08.1/ata4/host3/*", ENV{UDISKS_SYSTEM}="0"

[millpond]

We are not ignoring you, but i do not believe any of the more experienced users here are familiar with cryptab. Disk encrption is not very popular among those of us who have seen even the best of ext filesystems randomly lose files during an infrequent system freeze.

Personally, in your situation I would try multiple 'device' lines, assuming that one will work for both post and pre scanner use.
And double check that 0 for that global variable is correct. It seems to indicate root, but I have no clue as to the correct syntax.

Good luck!


PS. I would presume that the cause of the issue is systemd related, as it controls Udev, and its possible that the scanner might have triggered a pam or other security util in its ecosystem.

Edited to add: Doublecheck polkit

[Crumbs516]

Thanks for the response. I think you are probably right about the scanner triggering a systemd based device tree enumeration update. I was just hoping to get a decent reference to learn more about how it works.

I haven't had much time to go back to troubleshoot the root cause of this. I did put in 2 device lines when I discovered the problem. That seems to work just fine.

I appreciate the heads up on the data loss issue. Haven't yet lost anything due to encrypted filesystem corruption during system freeze, but have lost flash drives that way when the only solution was hard power off. I generally keep multiple copies of this sensitive data which I periodically sync. I think part of the issue is that I am using an internal encrypted drive in a non-standard way. Most of the examples I've seen people seem to mount them at boot/login time which I don't want. I only want the data unencrypted when it is actually needed not just because the system is on. Not being mounted as much marginally reduces the risk but really backing it up periodically is my real failsafe.

[millpond]

My only suggestion would be to make sure that the encryption system *will* restore from a backup.

Not all software does.
A good example is a typical website driven by MYSQL or one of its variants.
A straight backup will not work. The database file *must* be rendered into SQL script, and must be restored seperately.

Ideally, a secure encryption system should not be clonable. The reason i advise caution is because I have been the victim of poorly designed backup systems. Feeling secure, only to discover that when needed they lacked basic functions, like also backing up file permissions (assuming all backup media will be ext*.).