Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

"Virgilio, Vincent" <Vincent dot Virgilio at itt dot com> writes:
> I just updated to XFree86-xserv-4.3.0-47 from -46, and now have two
> problems:
> 
> 1. Clipboard integration is weakened in both 'twm' and multiwindow. I
> can copy/paste between X indows, but not between X and Windows (!).
> 
> 2. Tk/tcl widgets fail. I run one remotely for local display, and then
> see in the remote window:
> 
> X Error of failed request: BadAtom (invalid Atom parameter)
>   Major opcode of failed request: 18 (X_ChangeProperty)
>   Atom id in failed request: 0x114
>   Serial number of failed request: 370
>   Current serial number in output stream: 372
> 
> (I had to type that in by hand because of problem #1)
> 
> I'm not complaining: cygwin-xfree86 is still a great product. I thought
> this report might be helpful to the developers, if it's not just me.

It's not just you, and it's not the server.

I'm running Cygwin under Windows XP on an IBM Thinkpad T40.  I'm not
using the Cygwin X server; instead, I'm using the Hummingbird Exceed
server, version 7.  I'm running multiple xterm windows; my window manager
is fvwm2.  I've seen the same error using the Cygwin XFree86 server.

Just now, I tried to cut some text from an xterm window.  When I released
the mouse button, the xterm window died.  The parent window had an error
message identical to the one above (except that the atom id and serial
numbers were different).

I've tried backtracking to an older version of xterm, but so far I
haven't been able to correct the problem.  I have the latest versions
of just about everything, except that I've downgraded XFree86-bin from
4.3.0-9 to 4.3.0-8.

Here's the output of "cygcheck -c | grep XFree86":

XFree86-base            4.3.0-1            OK
XFree86-bin             4.3.0-8            OK
XFree86-bin-icons       4.3.0-6            OK
XFree86-doc             4.3.0-1            OK
XFree86-etc             4.3.0-6            OK
XFree86-f100            4.2.0-3            OK
XFree86-fcyr            4.2.0-3            OK
XFree86-fenc            4.2.0-3            OK
XFree86-fnts            4.2.0-3            OK
XFree86-fscl            4.2.0-3            OK
XFree86-fsrv            4.3.0-7            OK
XFree86-html            4.3.0-1            OK
XFree86-jdoc            4.3.0-1            OK
XFree86-lib             4.3.0-1            OK
XFree86-lib-compat      4.3.0-2            OK
XFree86-man             4.3.0-3            OK
XFree86-nest            4.3.0-5            OK
XFree86-prog            4.3.0-13           OK
XFree86-prt             4.3.0-5            OK
XFree86-ps              4.3.0-1            OK
XFree86-startup-scripts 4.2.0-5            OK
XFree86-vfb             4.3.0-5            OK
XFree86-xserv           4.3.0-47           OK
XFree86-xwinclip        4.3.0-2            OK

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

In my previous message, I missed a major piece of the puzzle.

The xterm windows that are dying mysteriously are running on a Solaris
system, not on my laptop under Cygwin.

Here's the scenario.  My laptop is "baldur" (IBM Thinkpad T40, Windows
XP, Cygwin); my Sun workstation is "elmak" (Sun Blade 100, Solaris 8).

On Baldur, I run the Hummingbird Exceed version 7 X server and the fvwm2
window manager (neither of which seems to be relevant).  From an xterm
window on baldur, I run

    xterm -e ssh elmak &

This gives me a shell on elmak running in an xterm window on baldur.
With OpenSSH X11 forwarding, I have $DISPLAY set to 'elmak:7.0'.

On elmak, I run

    xterm &

Now I have a second shell on elmak, this one in an xterm window running
on elmak but displayed on baldur.  No further forwarding is needed,
so the new shell also has $DISPLAY set to 'elmak:7.0'.

I can run X clients, such as xlogo, from any of these three windows,
and they display properly.

In the first two xterm windows, I can cut-and-paste.  In the third (the
Solaris xterm), if I try to highlight a region of text, the xterm dies
as soon as I release the mouse button, and the parent window gets:

xterm:  warning, error event receieved:
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0xb6
  Serial number of failed request:  277
  Current serial number in output stream:  279

This problem first showed up in the last few days, when I updated a
bunch of XFree86 packages through the Cygwin setup utility.

This isn't specific to Solaris.  I get the same symptom with an
xterm running on a variety of systems, including Red Hat with
XFree86-4.3.0-2.90.55, AIX, and SunOS 4.1.3 with X11R6.3.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

Another couple of data points:

I don't need so many xterms to reproduce the problem.  I can just ssh
from baldur (in a non-xterm window) to elmak, then run a single xterm
from there, and I see the same symptom.

If I run rxvt rather than xterm, I get:

rxvt: XError: Request: 18 . 0, Error: 5

emacs (in X mode) gives me a segmentation fault.

xedit gives me the same error as xterm.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

It looks like the problem has to do with the new OpenSSH package.

I tried logging into my Solaris box using SecureCRT, a Windows SSH client,
and then starting up an xterm from there; cut-and-paste worked correctly.

Now I've re-upgraded all the XFree86 packages and downgraded OpenSSH to
OpenSSH_3.7.1p2, and cut-and-paste still works correctly.

It looks like there's a problem with X forwarding in the new OpenSSH
package.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Igor Pechtchanski]

On Thu, 26 Feb 2004, Keith Thompson wrote:

> It looks like the problem has to do with the new OpenSSH package.
>
> I tried logging into my Solaris box using SecureCRT, a Windows SSH client,
> and then starting up an xterm from there; cut-and-paste worked correctly.
>
> Now I've re-upgraded all the XFree86 packages and downgraded OpenSSH to
> OpenSSH_3.7.1p2, and cut-and-paste still works correctly.
>
> It looks like there's a problem with X forwarding in the new OpenSSH
> package.

>From the new OpenSSH-3.8p1-1 announcement:

* ssh(1) now uses untrusted cookies for X11-Forwarding.
  Some X11 applications might need full access to the X11 server,
  see ForwardX11Trusted in ssh(1) and xauth(1) for more information.

Haven't looked further...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

On Thu, Feb 26, 2004 at 03:00:42PM -0500, Igor Pechtchanski wrote:
> On Thu, 26 Feb 2004, Keith Thompson wrote:
> 
> > It looks like the problem has to do with the new OpenSSH package.
> >
> > I tried logging into my Solaris box using SecureCRT, a Windows SSH client,
> > and then starting up an xterm from there; cut-and-paste worked correctly.
> >
> > Now I've re-upgraded all the XFree86 packages and downgraded OpenSSH to
> > OpenSSH_3.7.1p2, and cut-and-paste still works correctly.
> >
> > It looks like there's a problem with X forwarding in the new OpenSSH
> > package.
> 
> >From the new OpenSSH-3.8p1-1 announcement:
> 
> * ssh(1) now uses untrusted cookies for X11-Forwarding.
>   Some X11 applications might need full access to the X11 server,
>   see ForwardX11Trusted in ssh(1) and xauth(1) for more information.

Thanks.  Adding
    ForwardX11Trusted yes
to my $HOME/.ssh/config did the trick.

(Oddly, I never saw the problem on my Windows 2000 system, only on
Windows XP.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

RE: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Andrew Braverman]

That solved my problem as well.  Thanks.

-Andy

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com
> [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Igor Pechtchanski
> Sent: Thursday, February 26, 2004 3:01 PM
> To: cygwin-xfree@cygwin.com
> Cc: Keith Thompson
> Subject: Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.
> 
> 
> On Thu, 26 Feb 2004, Keith Thompson wrote:
> 
> > It looks like the problem has to do with the new OpenSSH package.
> >
> > I tried logging into my Solaris box using SecureCRT, a 
> Windows SSH client,
> > and then starting up an xterm from there; cut-and-paste 
> worked correctly.
> >
> > Now I've re-upgraded all the XFree86 packages and 
> downgraded OpenSSH to
> > OpenSSH_3.7.1p2, and cut-and-paste still works correctly.
> >
> > It looks like there's a problem with X forwarding in the new OpenSSH
> > package.
> 
> >From the new OpenSSH-3.8p1-1 announcement:
> 
> * ssh(1) now uses untrusted cookies for X11-Forwarding.
>   Some X11 applications might need full access to the X11 server,
>   see ForwardX11Trusted in ssh(1) and xauth(1) for more information.
> 
> Haven't looked further...
> 	Igor
> -- 
> 				http://cs.nyu.edu/~pechtcha/
>       |\      _,,,---,,_		pechtcha@cs.nyu.edu
> ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
>      |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
>     '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "I have since come to realize that being between your mentor 
> and his route
> to the bathroom is a major career booster."  -- Patrick Naughton
> 
> 

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Alexander Gottwald]

Harold L Hunt II wrote:

> I was wondering if this change in behavior meant that our multi-window
> window manager would be unable to connect to the server when an ssh
> session had been opened on the local machine already.  I did some
> testing but was not able to cause this to happen.  In any case, my great
> ideas for what was causing this problem are useless :)

More explanation i got from http://www.xfree86.org/~herrb/security.pdf

Any "normal" xclient connects in trusted mode. But openssh now connects
in untrusted mode. This is for "security" reasons. I'll describe later
why I think it's useless.

In untrusted mode some calls (esp. GetProperty and SetProperty) will fail.
This can be configured in /usr/X11R6/lib/X11/xserver/SecurityPolicy.

<quote source="SecurityPolicy">
# Allow reading of application resources, but not writing.
property RESOURCE_MANAGER   root    ar iw
property SCREEN_RESOURCES   root    ar iw

# Ignore attempts to use cut buffers.  Giving errors causes apps to crash,
# and allowing access may give away too much information.
property CUT_BUFFER0    root    irw
property CUT_BUFFER1    root    irw
</quote>

The CUT_BUFFER entries may explain why the problems with copy&paste started.

One way to solve the new problems is to modify the SecurityPolicy and
distribute it with the xserver. But this is complicated because
a) we have to figure out all properties which are safe to export
b) we may get responsible and sued for any security problem we create with
   these changes.

The other way is to enable X11ForwardTrusted by default. But again it is
(in my opinion) "dangerous" to explicitly disable a security method.

But anyway. I think the change to untrusted clients is very shortminded.

Most users will get annoyed with not working software and skip the whole
X11Forwarding issue and use "xhost +" again. This is a severe loss of
security.

If a lot of software requires access to properties which are blocked in
untrusted mode then most people will enable the switch. Only a few will
ever want the clients to connect in untrusted mode.

bye
    ago

NP: grauzone.04-02-15
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Harold L Hunt II]

Alexander,

Alexander Gottwald wrote:

> Virgilio, Vincent wrote:
> 
> 
>>when using ssh and X-forwarding (now with ForwardX11Trusted = yes)? It
>>looks like I have cookies in the right place. xauth report the same ones
>>on both the local and remote machine. Though, I have gnawing concerns
>>about the host part of the display name in those cookies; the
>>(alphabetic) cases do not match. Hum. I should try to share cookies
>>again (xauth extract, scp, xauth merge).
> 
> 
> It is an issue how the xserver handles untrusted clients. Until openssh
> 3.8 all clients forwarded by ssh were trusted by default. Now they are
> untrusted by default.

Wow, good thing I haven't commented on this yet.  I upgraded to OpenSSH 
3.8 when it came out and since then have noticed that all of my ssh 
connections (even those done by cvs) were enabling X11 forwarding by 
default.  I thought this was interesting, particularly since it wasn't 
mentioned in the release notes.  I was just about to describe how this 
change was made in OpenSSH 3.8 and how I am really smart because I am 
the only one that noticed it... then I realized:

1) My ssh_config is modified to enable X11Forwarding (I don't have to 
use -X, but I always do because I had forgotten that I changed this 
default).

2) I had installed SFU 3.5 at about the same time that I upgraded to 
OpenSSH 3.8.  Turns out that SFU 3.5 adds DISPLAY=127.0.0.1:0.0 to the 
global environment variables.

The combination of these two meant that ssh was acting as if it was 
getting passed a -X and it had a valid DISPLAY value at all times, so it 
was enabling X11 forwarding at all times.

I was wondering if this change in behavior meant that our multi-window 
window manager would be unable to connect to the server when an ssh 
session had been opened on the local machine already.  I did some 
testing but was not able to cause this to happen.  In any case, my great 
ideas for what was causing this problem are useless :)

Harold

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Alexander Gottwald]

Virgilio, Vincent wrote:

> when using ssh and X-forwarding (now with ForwardX11Trusted = yes)? It
> looks like I have cookies in the right place. xauth report the same ones
> on both the local and remote machine. Though, I have gnawing concerns
> about the host part of the display name in those cookies; the
> (alphabetic) cases do not match. Hum. I should try to share cookies
> again (xauth extract, scp, xauth merge).

It is an issue how the xserver handles untrusted clients. Until openssh
3.8 all clients forwarded by ssh were trusted by default. Now they are
untrusted by default.

I have no complete overview what the X11 Security Extension works and
which functions are prohibited but I'll take a look and try to match
this with the described error pattern.

Stay tuned.
    ago
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Virgilio, Vincent]

Keith and Igor, thanks for this thread

http://cygwin.com/ml/cygwin-xfree/2004-02/msg00288.html.

The reasoning is still beyond my ken, mostly because I haven't yet
digested the right set of man pages.

Nonetheless, it solved my problem, as described in

http://cygwin.com/ml/cygwin-xfree/2004-02/msg00262.html,

which was my just dessert for wielding Cygwin setup.exe so freely.

(I'm not on the cygwin-xfree list anymore, hence the links instead of a
simpler 'reply'.)

Incidentally, should I be seeing

	Warning: No xauth data; using fake authentication data for X11
forwarding.

when using ssh and X-forwarding (now with ForwardX11Trusted = yes)? It
looks like I have cookies in the right place. xauth report the same ones
on both the local and remote machine. Though, I have gnawing concerns
about the host part of the display name in those cookies; the
(alphabetic) cases do not match. Hum. I should try to share cookies
again (xauth extract, scp, xauth merge).

Ultimately, the above message is only unaesthetic; I haven't noticed
that it impacts performance.

Thanks and regards,

Vince Virgilio

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************

XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Virgilio, Vincent]

I just updated to XFree86-xserv-4.3.0-47 from -46, and now have two
problems:

1. Clipboard integration is weakened in both 'twm' and multiwindow. I
can copy/paste between X indows, but not between X and Windows (!).

2. Tk/tcl widgets fail. I run one remotely for local display, and then
see in the remote window:

X Error of failed request: BadAtom (invalid Atom parameter)
  Major opcode of failed request: 18 (X_ChangeProperty)
  Atom id in failed request: 0x114
  Serial number of failed request: 370
  Current serial number in output stream: 372

(I had to type that in by hand because of problem #1)

I'm not complaining: cygwin-xfree86 is still a great product. I thought
this report might be helpful to the developers, if it's not just me.

Regards,

Vince Virgilio


XFree86-xserv-4.3.0-47

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************