We’re working on customer premises quite regularly, carrying lots of documents and code with us on “portable media”. Of course all that is encrypted and we’ve set things up to decrypt & automount those file systems when logging on to the Linux hosts on-site.
Recently, we’ve switched from “USB sticks” to SSDs – 1.8 inch drives are small enough to carry around, and Delock has a nice 1.8″ USB 3.0 external disk case with a pouch to go with our SSDs. Hopefully the SSDs will prove to be less limiting and more reliable than the thumb drives – first tests have been quite promising, as was to be expected considering the much higher costs.
But when we ordered new units to compliment our initial test device, we noticed something that we so far had only suffered from when buying rather cheap USB sticks: All units resolved to the same, udev-generated entry in /etc/disk/by-id!
Quick tests showed that udev uses the type information of the disk, but the serial number as reported at the link layer – thus it’s the serial number of the USB enclosure, not that of the disk.
Of course, we’ve contacted Delock’s support staff – and were told that “the devices are of course using cheapo USB chipsets” and that they see no possible change to the behavior. They’d report it to their development, but wouldn’t want us to hold our breath. Of course we won’t, there’s no use in turning blue due to suffocation, is there?
Update: We’ve received another response from DeLock, in form of a tool to update the serial number reported by the disk enclosure! Once we’ve completed our tests, I’ll report the results.
Update 2: While we haven’t been able to find out if we may re-distribute the tool, I can happily confirm that the tool does it’s job – we’ve been able to change the serial number of the enclosure, making each and everyone unique. The program is for “MS Windows” only (not Linux), and is much more than a simple “change the serial number” tool. One of the effects is that the resulting serial number will be one higher than the start value you enter.
(By the way, getting in contact with Delock wasn’t as easy as I made it sound: The message sent via feedback form on their site got no timely response and calling the phone number resulted in some “unavailable” message. But our admin found a number to call that at last got him in contact with their support staff.)
Why is this important to us anyhow? The technical background is quite easy: Every “traveling developer” has its own personal disk. The encrypted partition is presented to the rest of the system as a (usually uniquely named) /dev/disk/by-id/…-partX device, so that pam_mount can pick that up (per per-developer configuration) and use an encryption key from some other source to decrypt that specific partition.
At many sites, only a single developer is logging on to a development machine at any point in time. No problem there.
But at the more sophisticated installations, the USB devices are simply handed on to a central development super-host, where *all* developers log in concurrently. Without changing the distribution’s udev ruleset, all encrypted partitions would resolve to a single, common id (constructed out of the SSD device description, the USB enclosure’s serial number and the partition name, like “/dev/disk/by-id/usb-TS32GSSD_18S-M_0000000000000033-0:0-part7”), making it impossible for pam_mount to decrypt different devices for different developers. Bummers.
How to handle the situation? We cannot return the devices, so we’ll have to stick with them. We’ll have to see if we can create a logistical situation (handing out these disks to only those developers not working on a common develop server) or can influence all target admins to change the udev rules.
If someone from Delock stumbles over this message: Hey, you have done good in getting a positive reputation, even in the professional market. Don’t spoil it easily… those few cents you saved on manufacturing such devices may cost you big money when losing customers!
See the update a some paragraphs above: We’ve received another response from DeLock, in form of a tool to update the serial number reported by the disk enclosure! My trust in DeLock is re-established!