Bug 676034
| Summary: | volume_key --save: - Error creating `packet': GPGME: Bad passphrase | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Miroslav Vadkerti <mvadkert> |
| Component: | doc-Technical_Notes | Assignee: | Ryan Lerch <rlerch> |
| Status: | CLOSED NOTABUG | QA Contact: | ecs-bugs |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.1 | CC: | mhideo, mitr, tmraz |
| Target Milestone: | rc | Keywords: | Documentation |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 05:31:07 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: | |||
| Bug Depends On: | 637902 | ||
| Bug Blocks: | |||
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? 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? 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. Tomas, please which package actually calls pinentry-gtk binary? That one should include it as a dependency. 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. 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. Maybe I misunderstood the bug - do you see the problem happen only when you have the DISPLAY environment variable set? 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. 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 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. Thanks for the comments, should these workarounds be documented somewhere? I added technical note explaining both problems and workarounds.
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.
(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"? 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.
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.
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
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
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. The Deployment Guide for Red Hat Enterprise Linux 6 does not document volume_key. Moving to the Storage Administration Guide. Storage Admin doesn't document this. Moving to Technical Notes as per comment 21 |
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.