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.
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.
*** This bug has been marked as a duplicate of 150262 ***