Bug 150184 - Oracle 9iAS forms designer cannot open display
Oracle 9iAS forms designer cannot open display
Status: CLOSED DUPLICATE of bug 150262
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xorg-x11 (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-03 09:35 EST by Scott Sibert
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-06 10:53:09 EST
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 Scott Sibert 2005-03-03 09:35:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4

Description of problem:
I have Oracle 9iAS rel1 running on Red Hat Enterprise Linux 2.1.  I had RHEL3 installed on my laptop and would run the Forms Designer (f60desm) from the server and display to my laptop.  It worked fine with RHEL3 WS on my laptop.  Since upgrading to RHEL4 WS (upgrade, not fresh install), when I try to run the Forms Designer I get this error:

[banner6@inb6b fmb]$ f60desm &
[1] 19788
[banner6@inb6b fmb]$ X Error of failed request:  BadAtom (invalid Atom parameter )
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0x1d1
  Serial number of failed request:  350
  Current serial number in output stream:  351

[1]+  Exit 1                  f60desm
[banner6@inb6b fmb]$


Version-Release number of selected component (if applicable):
xorg-x11-6.8.1-23.EL

How reproducible:
Always

Steps to Reproduce:
1. on RHEL4 WS, ssh to the Oracle9iAS server
2. run f60desm
3. read error message
  

Actual Results:  got this:

[banner6@inb6b fmb]$ f60desm &
[1] 19788
[banner6@inb6b fmb]$ X Error of failed request:  BadAtom (invalid Atom parameter )
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0x1d1
  Serial number of failed request:  350
  Current serial number in output stream:  351

[1]+  Exit 1                  f60desm
[banner6@inb6b fmb]$


Expected Results:  the Forms Designer GUI should have displayed on my laptop.

Additional info:

Nothing on the Red Hat Enterprise Linux 2.1 machine has changed and the Forms Designer runs and displays correctly when run on that machine's console.
Comment 2 Mike A. Harris 2005-03-06 10:52:21 EST
Thanks for your report.  The cause of this is documented in the Red Hat
Enterprise Linux 4 release notes, with respect to "openssh" configuration
defaults.

The problem described in this report, is caused by a change made by the
openssh project to the default configuration and operation of ssh.  In the
version of ssh you are using, the default X11 forwarding policy only
forwards clients as "untrusted", which restricts the operations X11
clients can do via the X-SECURITY extension.

Since most applications are not capable of dealing with running in the
restrictive X-SECURITY environment, most applications do not properly
catch and handle the errors Xlib returns when the client tries to do
something not permitted by X-SECURITY.

The symptoms of this are seen by applications failing in a variety of ways,
either crashing with an Xlib error or SEGV'ing or some other application
malfunction.  Additionally, features like cut and paste, drag and drop,
and other functionality is disabled in this restrictive environment.

This can technically be considered a bug in the individual applications
that fail, since they do not handle being ran in the restricted
X-SECURITY environment, and do not handle errors cleanly, however
since almost all applications fail due to this, the only feasible
workaround is to run "ssh -Y" to remote hosts, or to reconfigure
the ssh client global or per-user configuration to force full "trusted"
X11 forwarding.

Customers should be warned however that full X11 forwarding should
only be used between highly trusted computer systems, as X11 forwarding
potentially gives the remote computer full control of the user's X session,
which may have serious security implications if the remote system is
malicious or compromised.  

Since we have received a large number of problem reports from Red Hat
Enterprise Linux 4 customers and Fedora Core users due to this openssh
project change of defaults, we are planning to release updated openssh
packages with the default configuration changed to disable X11 forwarding
completely, so that users get a consistent error message which is a bit
more obvious as to what the problem is.  Users can then enable X11 forwarding
more easily, or use the -X commandline option (currently it is -Y) and should
get the same behaviour as in previous OS releases.

We have an existing tracker for the upcoming openssh update, so I'll close
this bug report as a duplicate of the master tracker.

Thanks again for your report.
Comment 3 Mike A. Harris 2005-03-06 10:53:09 EST

*** This bug has been marked as a duplicate of 150262 ***

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