Bug 150184
| Summary: | Oracle 9iAS forms designer cannot open display | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Scott Sibert <ssibert> |
| Component: | xorg-x11 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | shillman |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-03-06 15:53:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Scott Sibert
2005-03-03 14:35:36 UTC
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. |