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.
Hi All,
Sorry, no "gpg" on the pull down, so I picked the closest sounding thing.
I am coming from the "community": Scientific Linux 6.1.
Would one of you please fix this fro me. I consider this a security bug, not that gpg is causing a security hazard, but that the "xhost +" workaround is a security hazard to run on a server.
I can run the following from the command prompt without problem:
/usr/bin/gpg -z 0 --output /mnt/ShinyStick \
/2011-11-29_OurStuffDump.gz.gpg \
-c /lin-bak/2011-11-29_OurStuffDump.gz
But, when I run it from a batch script. I do not get the graphical
pop up asking for my passphrase. Instead I get:
(pinentry-gtk-2:25253): Gtk-WARNING **: cannot open display: :0.0
gpg-agent[25252]: can't connect server: ec=4.16383
gpg-agent[25252]: can't connect to the PIN entry module: End of file
gpg-agent[25252]: command get_passphrase failed: No pinentry
gpg: problem with the agent: No pinentry
gpg: error creating passphrase: Operation cancelled
gpg: symmetric encryption of `/lin-bak/2011-11-29_OurStuffDump.gz' failed: Operation cancelled
The work around is to call "xhost +" before the call to gpg. This is a security hazard to do on a server. "xhost +127.0.0.1" and "xhost +192.168.255.10" do not work. It is "+" only: all or nothing at all.
Note: under EL 5.7, gpg just prompted for the passphrase on the command line. This I can live with. I do not have to have the fancy graphical pop up.
Many thanks,
-T
(In reply to comment #3)
> Where is the script run from? Is that from a regular user login session?
Typically, I run it from my Xfce launcher panel:
xterm -fn 8x16 -fg darkgreen -bg white -bdc -cc "33:48,37:48,45-47:48,38:48" -geometry 100x24+185+346 -exec sudo /home/linuxutil/backup-rn OurStuff
Also, the problem reproduces when run from an xterm after "su'ing" and issuing:
# /home/linuxutil/backup-rn OurStuff
(In reply to comment #5)
> OK, so the real problem here is the su/sudo call.
Actually not. The problem exists even from a terminal/xterm and you are already elevated to user=root. The "#" in the above means "root".
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Unfortunately without proper investigation through the regular support channels we cannot do much more with this bug report. The real cause of the problem is unknown.
Hi All, Sorry, no "gpg" on the pull down, so I picked the closest sounding thing. I am coming from the "community": Scientific Linux 6.1. Would one of you please fix this fro me. I consider this a security bug, not that gpg is causing a security hazard, but that the "xhost +" workaround is a security hazard to run on a server. I can run the following from the command prompt without problem: /usr/bin/gpg -z 0 --output /mnt/ShinyStick \ /2011-11-29_OurStuffDump.gz.gpg \ -c /lin-bak/2011-11-29_OurStuffDump.gz But, when I run it from a batch script. I do not get the graphical pop up asking for my passphrase. Instead I get: (pinentry-gtk-2:25253): Gtk-WARNING **: cannot open display: :0.0 gpg-agent[25252]: can't connect server: ec=4.16383 gpg-agent[25252]: can't connect to the PIN entry module: End of file gpg-agent[25252]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: error creating passphrase: Operation cancelled gpg: symmetric encryption of `/lin-bak/2011-11-29_OurStuffDump.gz' failed: Operation cancelled The work around is to call "xhost +" before the call to gpg. This is a security hazard to do on a server. "xhost +127.0.0.1" and "xhost +192.168.255.10" do not work. It is "+" only: all or nothing at all. Note: under EL 5.7, gpg just prompted for the passphrase on the command line. This I can live with. I do not have to have the fancy graphical pop up. Many thanks, -T