Cryptsetup fails to mount the TrueCrypt system partition, when booting from the same disk

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a dual-boot setup with Windows and Linux
2. Encrypt the Windows System partition using TrueCrypt
3. Boot into linux and try to tcryptOpen the Windows partition using cryptsetup:

cryptsetup tcryptOpen /dev/sda truecrypt --tcrypt-system

What is the expected output? What do you see instead?
The intent is to have the decrypted system partition mapped to 
/dev/mapper/truecrypt
However, the command fails with message: 
"Cannot use device /dev/sda which is in use (already mapped or mounted)."

What version of the product are you using? On what operating system?
1.6.1+ / Linux

Please provide any additional information below.

This is kind of related to the issue #183 in terms of the underlying cause, but 
logging as a separate issue since it's a completely different use case and is 
more severe, I think. The problem here is that with the --tcrypt-system option, 
cryptsetup expects the disk identifier (/dev/sda) to be specified as the device 
parameter, instead of the partition identifier (/dev/sdaX) that the user is 
trying to work with.

The failure occurs because cryptsetup tries to map /dev/sda, while /dev/sda2 
(linux root) is in use (mounted).

To address this problem, please consider accepting the partition identifier as 
the device parameter with --tcrypt-system, as it's much less ambiguous. 
Thereafter, I see a couple of possibilities (both may be implemented):

> add support for --master-key-file option to read the master key directly from 
a file or standard input, instead of decrypting the header. This is admittedly 
less secure, but is highly flexible and not something that cryptsetup already 
doesn't support for other encryption schemes
> read the volume header from LBA 0x3E on the disk that the partition resides 
on, and after decrypting the header/master key, ensure that the requested 
partition is contained within the master key scope.

This will also address the issue with Truecrypt's Whole Disk Encryption (WDE) 
scheme, where the master key scope covers more than one partition and provide 
the ability to decrypt/access any of those encrypted partitions using 
cryptsetup.

Cheers!

Original issue reported on code.google.com by y...@indiatimes.com on 3 Dec 2013 at 10:46

[GoogleCodeExporter]

Yes, accepting partition identifier seems to be correct solution here. (ditto 
for Issue#183). There is also already check  that partition is in scope of 
master key, it will just rewrite (currently it just expect 1:1 mapping - one 
partition).

...I just need to find time to implement it now:-)

Original comment by gmazyl...@gmail.com on 4 Dec 2013 at 5:17

[GoogleCodeExporter]

Should be fixed by commit
http://code.google.com/p/cryptsetup/source/detail?r=c57071a43a0d43d08faed85faaaf
39ad04e68797

which allows to use partition as a parameter with system encryption.

Please test git version if you can, thanks.

Original comment by gmazyl...@gmail.com on 7 Dec 2013 at 11:07

• Changed state: Started

[GoogleCodeExporter]

Original comment by gmazyl...@gmail.com on 7 Dec 2013 at 11:10

• Changed state: Fixed

[GoogleCodeExporter]

Successfully verified with git snapshot taken on 12/09/2013.

Test case: Mount an encrypted partition on a drive by specifying partition 
identifier (/dev/sdaX), when another partition (/dev/sdaY) is already mounted
Setup: /dev/sdaX is the TrueCrypt encrypted system partition, /dev/sdaY is an 
unencrypted ext3 partition already mounted as '/' (root))
Command: cryptsetup tcryptOpen /dev/sdaX sdaX_crypt --tcrypt-system
Result: PASSED

Test case: Mount multiple encrypted partitions on a drive by specifying 
respective partition identifier (/dev/sda*)
Setup: Partitions /dev/sdaX & /dev/sdaY are both encrypted with TrueCrypt Whole 
Disk Encryption (WDE)
Commands:
cryptsetup tcryptOpen /dev/sdaX sdaX_crypt --tcrypt-system
cryptsetup tcryptOpen /dev/sdaY sdaY_crypt --tcrypt-system
Result: PASSED

Thanks for fixing this!

Original comment by y...@indiatimes.com on 10 Dec 2013 at 7:12