Bug 676034 - volume_key --save: - Error creating `packet': GPGME: Bad passphrase
volume_key --save: - Error creating `packet': GPGME: Bad passphrase
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Technical_Notes (Show other bugs)
6.1
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Ryan Lerch
ecs-bugs
: Documentation
Depends On: 637902
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-08 11:58 EST by Miroslav Vadkerti
Modified: 2011-05-27 01:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (packages pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected. Workaround command: # unset DISPLAY
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-27 01:31:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Vadkerti 2011-02-08 11:58:42 EST
Description of problem:
When I follow these repro steps which we used for testing volume_key in EL6, I cannot save escrow packet:

# dd if=/dev/urandom of=testpartition bs=1M count=10
# losetup /dev/loop0 testpartition
# cryptsetup luksFormat /dev/loop0
(enter password)
# cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0
Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	256
MK digest:     	90 d0 d8 bd 49 40 eb c3 fa 3d 00 44 ea 59 37 36 c9 d1 e6 99 
MK salt:       	a6 e0 c8 84 24 5f d4 0b f8 dc 41 c9 9e 7f 1f 3d 
               	c8 a9 67 b9 c4 ad 57 31 90 d1 ea 75 b1 49 fd 28 
MK iterations: 	33000
UUID:          	f5d9431d-2428-4ab6-8e11-c4228a561249

Key Slot 0: ENABLED
	Iterations:         	132130
	Salt:               	44 9b c1 37 69 eb d2 2c 98 7f b0 70 e4 5c ff 8d 
	                      	68 ac 60 02 5b bb 82 83 a3 14 db 05 ad 30 80 e6 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

# volume_key --save /dev/loop0 -o packet  
Passphrase for `/dev/loop0': 
New packet passphrase: 
Repeat new packet passphrase: 
volume_key: Error creating `packet': GPGME: Bad passphrase
(I used strong password)

Version-Release number of selected component (if applicable):
gpgme-1.1.8-3.el6.x86_64
volume_key-0.3.1-5.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
see description
  
Actual results:
volume_key: Error creating `packet': GPGME: Bad passphrase

Expected results:
Packet is saved without issues

Additional info:
Tested on x86_64 architecture.
Comment 2 Miloslav Trmač 2011-02-10 10:48:11 EST
I have seen similar behavior with volume_key-0.3.1-3 when pinentry-gtk was not installed.

In particular, without X there was be a full-screen PIN dialog and everything worked fine; in gnome-terminal volume_key failed as described as above, but installing pinentry-gtk fixed this.

Could you check if you see the same behavior, please?
Comment 3 Miroslav Vadkerti 2011-02-11 07:53:17 EST
I can confirm that installing pinentry-gtk fixes this issue. Thanks very much. Should volume_key or gpgme have this package as dependency in this case?
Comment 4 Miloslav Trmač 2011-02-11 08:13:54 EST
Neither - both are supposed to provide a passphrase without any user interaction: this bug is essentially another manifestation of #637902.

Perhaps gnupg2 should add the pinentry-gtk dependency, I'm not sure.
Comment 5 Miroslav Vadkerti 2011-02-11 08:55:00 EST
Tomas, please which package actually calls pinentry-gtk binary? That one should include it as a dependency.
Comment 6 Tomas Mraz 2011-02-11 09:26:58 EST
No, I don't think that there should be a hard dependence on pinentry-gtk. This package should be in comps default so it is normally installed on systems with X/gtk. But it should not be pulled as a hard dependency of gnupg2.
Comment 7 Miroslav Vadkerti 2011-02-11 09:47:28 EST
But if I have a server installation without X/gtk packages installed (which would pull in pinentry-gtk) and I want to use volume_key -> how should I know I need to install pinentry-gtk? If volume_key won't work without pinentry_gtk it should require it or should print a reasonable error message why passphrase cannot be entered.
Comment 8 Tomas Mraz 2011-02-11 10:00:24 EST
Maybe I misunderstood the bug - do you see the problem happen only when you have the DISPLAY environment variable set?
Comment 9 Tomas Mraz 2011-02-11 10:29:13 EST
So the situation is that when pinentry-gtk is not existing in the system and the DISPLAY is set the pinentry script will fail. It would be probably more appropriate to run pinentry-ncurses in such situation, perhaps at least in case a tty is available.
Comment 10 Stanislav Ochotnicky 2011-02-14 04:15:49 EST
Hmm, if you have server installation without X, why is your DISPLAY set? I am guessing remote ssh with X redirect? That means you must have xauth installed on the machine so it's not completely X-less.

On pinentry side there is simple workaround for this: unset DISPLAY before using anything that requires pinentry when you don't have graphical pinentry subpackage installed.

I'll see about the rest of problems
Comment 11 Stanislav Ochotnicky 2011-02-14 04:57:01 EST
OK, there seems to be problem with running gpg/pinentry as root. Therefore for volume-key to work one needs to run gpg-agent as a normal user and then supply GPG_AGENT_INFO in root shell. I was able to succesfully execute "volume_key --save /dev/loop0 -o packet" like this.
Comment 12 Miroslav Vadkerti 2011-02-14 05:31:37 EST
Thanks for the comments, should these workarounds be documented somewhere?
Comment 14 Stanislav Ochotnicky 2011-02-14 11:17:53 EST
I added technical note explaining both problems and workarounds.
Comment 15 Stanislav Ochotnicky 2011-02-14 11:17:53 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully. 

Additionally pinentry-ncurses fails if current tty is owned by different user as the one running pinentry. This happens for example when users does "su -" after logging in as normal user. The /dev/pts/XX file is not chown-ed to root and therefore pinentry-ncurses fails. If you want to run pinentry after doing "su -", you need to chown current pts to root.
Comment 16 Miloslav Trmač 2011-02-14 13:16:18 EST
(In reply to comment #15)
> Additionally pinentry-ncurses fails if current tty is owned by different user
> as the one running pinentry. This happens for example when users does "su -"
> after logging in as normal user. The /dev/pts/XX file is not chown-ed to root
> and therefore pinentry-ncurses fails. If you want to run pinentry after doing
> "su -", you need to chown current pts to root.
Won't chowning the TTY break the user's session after exiting from "su"?
Comment 17 Miroslav Vadkerti 2011-02-15 10:45:12 EST
So after sochotni investigation there is a bug in pinetry and the issue will be separately tracked by bug 677665. I removed the workaround from technical notes and I'm contacting content services to help me adding this to GSS knowledge base.
Comment 18 Miroslav Vadkerti 2011-02-15 10:45:12 EST
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1 @@
-If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully. 
+If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully.-
-Additionally pinentry-ncurses fails if current tty is owned by different user as the one running pinentry. This happens for example when users does "su -" after logging in as normal user. The /dev/pts/XX file is not chown-ed to root and therefore pinentry-ncurses fails. If you want to run pinentry after doing "su -", you need to chown current pts to root.
Comment 19 Miroslav Vadkerti 2011-02-15 11:43:50 EST
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,4 @@
-If no graphical (-qt or -gtk) pinentry is installed then DISPLAY has to be unset (no X forwarding has to be active). Otherwise pinentry assumes existence of gtk or qt backends and doesn't fail gracefully.+The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected.
+
+Workaround command:
+# unset DISPLAY
Comment 20 Miroslav Vadkerti 2011-02-15 11:45:04 EST
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,4 @@
-The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected.
+The DISPLAY environment variable was set but no graphical - Qt or GTK backend of the pinentry was installed (packages pinentry-gtk or pinentry-qt). Due to this issue, the volume_key command printed "volume_key: Error creating `packet': GPGME: Bad passphrase" although the user supplied the correct credentials. This workaround unsets the environment variable DISPLAY. Now, the volume_key works as expected.
 
 Workaround command:
 # unset DISPLAY
Comment 21 Stanislav Ochotnicky 2011-02-23 11:40:06 EST
Since this is not really a pinentry bug, just configuration error I am reassigning to doc team. This problem should probably be mentioned in one part of technical notes.
Comment 22 Jaromir Hradilek 2011-05-19 10:14:05 EDT
The Deployment Guide for Red Hat Enterprise Linux 6 does not document volume_key. Moving to the Storage Administration Guide.
Comment 23 Jacquelynn East 2011-05-27 00:19:10 EDT
Storage Admin doesn't document this. Moving to Technical Notes as per comment 21

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