Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 845698

Summary: crypttab coughs on passwords with space
Product: Red Hat Enterprise Linux 6 Reporter: Todd <ToddAndMargo>
Component: cryptsetup-luksAssignee: Milan Broz <mbroz>
Status: CLOSED CANTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: agk, atodorov, lnykryn, mbroz, prajnoha, prockai, pvrabec, zkabelac
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-10 06:53:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Todd 2012-08-03 22:28:52 UTC
Hi All,

I am coming from the "Community": Scientific Linux 6.2, 64 bit.  Would one of our interpret heroes at Red Hat please fix this for me?

I just encrypted my backup drives.  In the process, I found the /etc/crypttab will not accept passwords with spaces in them for the third (password) parameter.  Both

foo /dev/sdb1 "blah blah blah blah"
and
foo /dev/sdb1 blah\ blah\ blah\ blah

error out at boot time with the following error: "key file not found".  The work around is to put your password with spaces in it in a keyfile

If I may be so bold as to put my two cents in:

1) if you decide not to fix this (sob, tears), please alter the Man Page to state on the third parameter: Password with spaces in them are not supported directly in the third parameter.  To use a password with spaces, place the password in a key file.

or

2) if you decide to fix this (cheers!), please add to the Man Page: To use password with spaces in them, escape the spaces with (what ever you guys come up with).  Don't leave the user in the dark as to how to use passwords with spaces in them

Many thanks,
-T

Comment 2 Todd 2012-08-06 23:31:07 UTC
I have open a new bug on the manual page at:

crypttab tab man page password section needs to be updated
https://bugzilla.redhat.com/show_bug.cgi?id=846140

It contains my proposed updates to the manual page.  And includes modifications to encompass bug

https://bugzilla.redhat.com/show_bug.cgi?id=845701
Crypttab does not mount volume at boot 

as well.

Comment 3 Lukáš Nykrýn 2012-08-07 07:45:57 UTC
I am not sure if we can fix this (in initscripts) because of backward compatibility. Let say that there is someone happily using password like this\is"my'passsword.

Comment 4 Todd 2012-08-09 19:50:09 UTC
(In reply to comment #3)
> I am not sure if we can fix this (in initscripts) because of backward
> compatibility. Let say that there is someone happily using password like
> this\is"my'passsword.

¡Ay, caramba!  Me thinks the man page is the only solution (bug 846140).  Please go ahead and close this bug