Bug 788236

Summary:	encrypted swap uses passphrase
Product:	[Fedora] Fedora	Reporter:	Paul Bransford <draeath>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	16	CC:	anaconda-maint-list, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-07 21:19:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Paul Bransford 2012-02-07 20:16:08 UTC

If "encrypt" is selected during partitioning for the swap partition, this volume will use the same encryption key entered for any other volumes, and does not use cryptsetup's support for random key swap. There seems to be no way to override this during installation.

This results in redundant password prompts at boot, first for root, and again for the swap space.

Expected behavior is for the swap space to be encrypted/formatted with a random key each boot (and thus not supporting resume) OR that the passphrase entered for one volume be tried to unlock subsequent volumes.

Comment 1 Paul Bransford 2012-02-07 20:19:56 UTC

A workaround is to add an additional key to the swap LUKS volume using "cryptsetup luksAddKey /dev/foo" and then add this new passphrase to /etc/crypttab. This is only a good idea if root is already encrypted.

Comment 2 Paul Bransford 2012-02-07 20:33:34 UTC

Indeed, creating a keyfile (for example in /etc/luks/), adding it to the volume, and then changing "none" to this path+filename appears to work. On boot, my root volume is unlocked, then the keyfile stored in /etc is used to unlock the swap volume, which is then mounted.

Setting this up on installation is something that could be automated by Anaconda.

The suspend/resume on this hardware is a bit buggy, so I can't thoroughly test it's function with this.

Comment 3 Paul Bransford 2012-02-07 20:46:28 UTC

(In reply to comment #2)
> volume, and then changing "none" to this path+filename appears to work. On

Inside /etc/crypttab. Sorry for the multiple comments.

Comment 4 David Lehman 2012-02-07 21:19:17 UTC


*** This bug has been marked as a duplicate of bug 505518 ***