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 - crypttab coughs on passwords with space
Summary: crypttab coughs on passwords with space
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cryptsetup-luks
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Milan Broz
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-03 22:28 UTC by Todd
Modified: 2013-03-01 04:11 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-10 06:53:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.