Diskutil eject does not 're-lock' Filevault encrypted volumes on external drive

No. Password is not in my keychain for the logged in account.

Topher Kessler wrote:

Bizarre. If there is no keychain entry for the volume then it should not automatically unlock if and when detected by the system (ie, the keychain password is quite relevant to the unlock status of an encrypted drive).

Since you do not have such a password in yoru keychain, if you eject and then disconnect the drive does it show a locked status if you then reconnect it? Additionally, if you try to directly mount the drive in Disk Utility does it automatically mount or does it require a password regardless of the unlock status designated in the corestorage volume list?

It doesn't unlock automatically. What I'm saying is, if you unlock it once by manually entering the password (it is not in my keychain), then it is forever unlocked until the machine is rebooted. OSX documentation says that "diskutil eject" should re-lock the volume, but it doesn't. The volume can be re-mounted without re-entering the password (even though it is not in the keychain). The password must remain stored in memory somewhere even after the "diskutil eject" command is issued.

As I said in the original post, after issuing the "diskutil eject" command, the status of the drive still shows an unlocked status when running "diskutil corestorage list", even after the disk has been ejected.

The same behavior occurs if mount a locked disk and then unmount it using the graphical interface Disk Utility. No password stored in keychain. Manually enter the password, the disk mounts. Unmount the disk. It can be re-mounted from disk utility without entering the password a second time.

I tried logging out the user too. It doesn't matter. The only thing that re-locks the volume that I can discover is rebooting the computer.

This seems like a pretty big security hole for FileVault. Is Apple acknowledging this problem and working on a fix? How to bring it to their attention?

Linc Davis wrote:

Whether or not the password is saved in the keychain is irrelevant to the lock status of the volume. The volume is unlocked when the key is in memory, and locked otherwise. Your diskutil output shows an unlocked volume, and I confirmed the behavior. That makes it even more important to secure a system that handles encrypted HFS data from local attack. At a minimum, the screen must be locked whenever you're away from the machine.

I only have filevault enabled on my external drive.

You confirmed the behavior, but is yours an external or internal drive? Not sure it even matters. Could it be a problem with both?

M. Anthony Aiello wrote:

This is a major issue. It's incredible to me that a) more people have not identified this problem and b) Apple is not saying anything about it.

Note that not only does `diskutil eject` not work as advertised, ejecting the volume in Finder also does not lock it. There appears to be absolutely not way, short of disconnecting the media (e.g., yanking the USB/FireWire/Thunderbolt cable or pulling the disk from the enclosure) of re-enabling encryption.

How is this okay? How did Apple let this happen? And why hasn't anyone else identified it?

Maybe we're asking the wrong people. NSA? What do you think?

Still not fixed with OSX 10.9 (Mavericks). What's the deal here?

Are you sure about that? That is not what is being reported by the other people here on this forum.

I wonder what the difference is between what you are doing and what other people are experiencing. Do your disks have more than one partition on them? I don't think this should make a difference, but I will check.

It seems implausible that Apple has not had the capabiity to fix this problem over such a long time period. I have to wonder if the NSA is preventing them from doing so. At the very least, they could update their diskutil corestorage man pages (e.g. man diskutil) to reflect what the actual behavior is, rather than having left it for over a year now giving people the impression that ejecting an encrypted disk provides security, when it doesn't.