Bug 698261

Summary: subscription-manager cli requires X11 auth?
Product: Red Hat Enterprise Linux 5 Reporter: J.C. Molet <jmolet>
Component: subscription-managerAssignee: Chris Duryee <cduryee>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: 5.7CC: cduryee, mitr, spandey
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-20 18:38:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 675214    

Description J.C. Molet 2011-04-20 14:23:58 UTC 
Description of problem:
When running the cli to subscription manager, it requires X11 auth.

Version-Release number of selected component (if applicable):
subscription-manager-gnome-0.95.5.8-1.git.2.3d40137.el5
subscription-manager-firstboot-0.95.5.8-1.git.2.3d40137.el5
subscription-manager-0.95.5.8-1.git.2.3d40137.el5

How reproducible:
always

Steps to Reproduce:
[jmolet@xanadu ~]$ ssh -XYC root@jmolet-57server
[root@jmolet-57server ~]# su - testuser
[testuser@jmolet-57server ~]$ subscription-manager --help
X11 connection rejected because of wrong authentication.

Actual results:
you seem to get "X11 connection rejected because of wrong authentication." as long as the DISPLAY variable is set. 

Expected results:
This should only happen when running the gui components of the program, not the CLI components
Comment 1 Chris Duryee 2011-04-20 18:03:45 UTC 
This appears to be an issue with consolehelper.

If you connect to the testuser user via the method above, consolehelper thinks that X is available even when it isn't, and will try to execve consolehelper-gtk. You can test this out by running "eject", which is wrapped the same as subscription-manager is.

Note: I am not sure how to reproduce this setup, I was unable to repro locally so I had to use the box in question.
Comment 2 Chris Duryee 2011-04-20 18:15:21 UTC 
*** Bug 698260 has been marked as a duplicate of this bug. ***
Comment 3 Miloslav Trmač 2011-04-20 18:32:54 UTC 
This behavior of userhelper is intentional: only by using X can the password
dialog "grab" the keyboard, preventing other applications from snooping the
password.

My recommendation is to keep this behavior: users passing broken DISPLAY is,
IMHO, a configuration error that no software is required to work around.

If you insist on ignoring DISPLAY, you can, for example, set GUI=no in
/etc/security/console.apps/your_program.  See userhelper(8) for other options.