system startup + cryptsetup
Marc Schwartz
MSchwartz at mn.rr.com
Tue Mar 28 22:27:19 UTC 2006
Gabor Walter wrote:
>> That modification should solve the problem by explicitly assigning the
>> response to $answer. It will then be properly read in the 'case'
>> statement.
>
>
> That was it. Thanks a lot once again.
Happy to help.
> BTW, out of curiosity, did you modify /etc/fstab? Just wondering about
>> confirming new behavior, if any, in FC5, besides the LUKS changes to
>> gnome-mount, etc.
>
>
> Yes, I did make the modifications you suggested.
Ok. So at least for now, that part of the process is unchanged in FC5.
Thanks for that.
> Another question. Is it necessary to explicitly unmount and close the
> encrypted partition at shutdown? I am thinking of sort of a "reversed
> luksopen'. Or will the system take care of it all?
I have not seen anything convincing to suggest that you need to
explicitly unmount and close the mapped partition prior to shutdown. Of
course with /home, the timing of that activity could be important.
As far as I have seen from comments (or the lack of them) elsewhere, the
system will unmount the device at shutdown and the device mapping is
also lost at that time. I suppose that if for some reason, the shutdown
were interrupted in some fashion at the proper point, there might be a
window of opportunity for compromise of the system, but that seems like
a low probability scenario for most users.
There was a discussion of what luksClose actually does on the list I
reference below (ie. does it scrub the master key from memory, etc.),
but there was never a reply, so it remains unclear, presumably save a
read of the code.
I have seen comments about explicitly unmounting and closing when one is
using loopback devices rather than actual partitions, but since I don't
use loopback devices, I have no personal experience with them.
If you want a verified answer from the experts, there is a dedicated
e-mail list accessible via gmane's NNTP interface at:
http://news.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt
HTH,
Marc
More information about the fedora-list
mailing list