Bug 612940

Summary:	Fix man page to better describe passphrase input from stdin and terminal when --key-file=- is used
Product:	Red Hat Enterprise Linux 6	Reporter:	Pavel Holica <pholica>
Component:	cryptsetup-luks	Assignee:	Milan Broz <mbroz>
Status:	CLOSED WONTFIX	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	agk, borgan, dwysocha, mbroz, prockai, pvrabec
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-02-07 13:45:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pavel Holica 2010-07-09 11:09:35 UTC

Description of problem:
When --key-file=- is used, and password is typed in, reading ends when user presses enter and newline is stripped, but this shouldn't happen according to documentation.

From documentation:
If --key-file=- is used for reading the key  from  stdin,  no  trailing
newline  is  stripped  from  the input. Without that option, cryptsetup
strips trailing newlines from stdin input.

Version-Release number of selected component (if applicable):
cryptsetup-luks-1.1.2-1.el6

How reproducible:
always

Steps to Reproduce:
1. dd if=/dev/zero of=/tmp/encrypted.img count=1 bs=4k seek=100k
2. losetup /dev/loop0 /tmp/encrypted.img
3. echo -e "test\npass" | cryptsetup LuksFormat --from-file=- /dev/loop0
4. cryptsetup LuksOpen --from-file=- /dev/loop0 test_encrypted
5. type:
test
pass
  
Actual results:
No key available with this passphrase.
Reading ends when enter is pressed (after typing "test") and luks device cannot be opened.

Expected results:
Password should be read until EOF and device should be successfully opened. 

Additional info:

Comment 1 Milan Broz 2010-07-09 11:30:42 UTC

The is no --from-file switch. You mean --key-file?

You CANNOT enter passphrase conttaining \n from terminal. You can do it from stdin (using echo), but not directly from tty. (It checks inside if stdin is terminal or not.)

Please read man page. Which documentation is wrong?
...
From a terminal: Password processing is new-line sensitive, meaning the reading will stop after encountering \n.

Comment 2 Pavel Holica 2010-07-09 12:06:22 UTC

> The is no --from-file switch. You mean --key-file?
Yes, I meant --key-file.

> You CANNOT enter passphrase conttaining \n from terminal. You can do it from
> stdin (using echo), but not directly from tty. (It checks inside if stdin is
> terminal or not.)
Yes, that's what manpage says. It also sais, that when --key-file=- is used, password is read from stdin (not terminal).

> Please read man page. Which documentation is wrong?
> ...
> From a terminal: Password processing is new-line sensitive, meaning the reading
> will stop after encountering \n.
As I mentioned above, I used --key-file=- which should cause, that password is read from stdin (not terminal), and newlines shouldn't be stripped.

It's strange, that --key-file=- is ignored when stdin is a tty.

Comment 3 Milan Broz 2010-07-09 12:27:01 UTC

(In reply to comment #2)

> It's strange, that --key-file=- is ignored when stdin is a tty.

It is not strange (but the whole idea od processing \n is strange:-), it was such way always. If the input file is stdin, and stdin is terminal, it will strip newlines.

I'll fix upstream manpage to explicitly mention this, it is now quite confusing.
But this can be changed in 6.1 with other updates, nothing important for 6.0.

> It's strange, that --key-file=- is ignored when stdin is a tty.
it is not ignored, stdin is connected to tty here.

Comment 5 Milan Broz 2011-02-07 13:27:02 UTC

cryptsetup was rebased to 1.2.0 but I did not update this section, the manual page is IMHO clear. On terminal are newlines always processed.

If you want add this some not to FAQ, please report it upstream (FAQ file was added to 6.1 as well).

Comment 6 RHEL Program Management 2011-02-07 13:45:08 UTC

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.