Hide Forgot
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
There should be other possible workarounds to this problem that do not create this wide open hole to the X server.
Where is the script run from? Is that from a regular user login session?
(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
OK, so the real problem here is the su/sudo call.
(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.