Bug 104713 - rdesktop to windows 2000 command window shows screen saver password
rdesktop to windows 2000 command window shows screen saver password
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: rdesktop (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
bzcl34nup
:
: 129055 132492 (view as bug list)
Depends On:
Blocks: 344471
  Show dependency treegraph
 
Reported: 2003-09-19 12:17 EDT by Pete Reetz
Modified: 2013-03-05 22:40 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 19:57:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rdesktop-1.3.1-only-grab-keyboard-in-fullscreen.patch (815 bytes, patch)
2004-09-30 06:23 EDT, Mark McLoughlin
no flags Details | Diff

  None (edit)
Description Pete Reetz 2003-09-19 12:17:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
RedHat 9

When typing screen saver password, if the last active window was a command
prompt on a windows 2000 rdesktop session - the typed value will show up in the
command window and execute.

Version-Release number of selected component (if applicable):
rdesktop-1.2.0

How reproducible:
Always

Steps to Reproduce:
1. rdesktop into windows 2000 machine running terminal server
2. open a command prompt and make sure window is active
3. allow screen saver with locking to turn on
4. enter password to unlock screen saver

    

Actual Results:  notice that the password was executed in the command window

Expected Results:  unlock screen saver with no trace of password showing up
anywhere on the desktop

Additional info:
Comment 1 Peter Åstrand 2003-09-23 05:38:23 EDT
This is a very general problem. When rdesktop is running in fullscreen mode, it
grabs the keyboard, just like any other sane fullscreen application.
xscreensaver wants to grab the keyboard to, but fails since another application
has already grabbed. 

So, this is not only a problem with rdesktop, but with many other apps as well.
As I understand it, *all* GTK apps that uses GTK:s built-in fullscreen code has
this problem as well. For example, "GQview" also has problems: I just tried
runnning it in fullscreen mode and locked the screen. In this case, I was unable
to unlock the display, because all keyboard input went to GQview. 

The whole X11/fullscreen story is a mess. There's a real need for a policy
document/HOWTO specifying exactly how fullscreen apps should work. Something for
freedesktop.org, perhaps?

Since I'm the maintainer for the keyboard stuff in rdesktop, I would be glad if
we could find a solution to this problem, but currently I have no idea of how it
should be done. 
Comment 2 Alexander Larsson 2003-09-23 06:15:22 EDT
hp: Ideas?
Comment 3 Jamie Zawinski 2004-03-04 15:41:46 EST
I don't know why you say that a "full screen program" must grab the
keyboard: that's completly untrue!  Grab the focus, perhaps, but not
the keyboard.  The only reason to grab  the keyboard is to ensure that
you get keyboard event when you *do not* have the focus!  If you have
focus, you're going to get the events anyway.  And if your window is
covering the screen, then you're going to have focus.

So there's no reason to do this grab, but the side effect is that
xscreensaver is incapable of grabbing when the time comes to lock the
screen.  Since xscreensaver is not receiving keyboard events, it can't
tell that the user is typing their password to unlock the screen.

There is no way to work around this in xscreensaver: rdesktop must be
fixed instead.   Please stop grabbing the keyboard for indefinite
periods.  It breaks everything.
Comment 4 Havoc Pennington 2004-03-06 14:26:00 EST
GTK's fullscreen mode doesn't grab the keyboard... check again whether
you are doing it elsewhere.

People have said good things about how totem fullscreen works.

with rdesktop arguably it should take over the session in fullscreen
mode (you're essentially entering "windows mode" and can't escape),
when doing this it would behave just like xscreensaver's screen
locking I suppose. But then you need some way to keep the screensaver
from kicking in (this is needed anyway for e.g. slideshows)
Comment 5 Peter Åstrand 2004-03-06 16:12:25 EST
You are correct: GTK's fullscreen mode doesn't grab the keyboard; it's
GQView that does. I wonder why. I also wonder if you know of any other
GTK application with fullscreen support that does not grab the
keyboard. I'm prepared to try removing the grab from rdesktop, but I'd
like to see an application working without the grab first. 
Comment 6 Jamie Zawinski 2004-09-02 17:39:08 EDT
gqview just fixed that bug:

https://sourceforge.net/tracker/?func=detail&atid=104050&aid=910085&group_id=4050
Comment 7 Mark McLoughlin 2004-09-24 11:21:06 EDT
*** Bug 132492 has been marked as a duplicate of this bug. ***
Comment 9 Dax Kelson 2004-09-24 11:31:19 EDT
rdesktop doesn't have to be full screen for this to occur.

I never run rdesktop full screen, and it happens to me frequently.
Comment 10 Mark McLoughlin 2004-09-24 11:40:20 EDT
Could someone try with "rdesktop -K" and see if that helps matters?
Comment 11 Dax Kelson 2004-09-24 12:10:50 EDT
I just tested with -K and it no longer captures the screensaver
passwords, however ALT+TAB, CTL+ALT+DELETE and other keystrokes no
longer work on the windows host even when rdesktop has focus, they
operating locally.

Comment 12 Mark McLoughlin 2004-09-30 06:21:37 EDT
(twaugh: cc-ing you, the keyboard grab with fullscreen and the
xscreensaver lock dialog issue applies to vncviewer too)

Okay, so in the case of rdesktop and vncviewer they're grabbing the
keyboard for a fairly legitimate reason - you want key combinations
like Alt-Tab to go to the session on the server machine rather than
getting trapped by the local window manager.

Possibly we could work out some protocol with the window manager to
indicate that all global key grabs should be dropped for certain
fullscreen windows?

However, rdesktop differs from vncviewer in one specific way - it will
grab the keyboard (for the same reason) whenever the window has
*focus* and it grabs focus on EnterNotify.

I think it feels reasonably sensible if we only grab the keyboard when
the window is fullscreen. When you can see the window decorations and
the other windows I think it makes sense for the local window manager
keybindings to work as normal.

Attaching a patch which should make us only grab the keyboard with
fullscreen. I don't have the ability to easily test it - Dax could you
possibly test the patch?
Comment 13 Mark McLoughlin 2004-09-30 06:23:04 EDT
Created attachment 104575 [details]
rdesktop-1.3.1-only-grab-keyboard-in-fullscreen.patch
Comment 14 Mark McLoughlin 2004-09-30 06:38:42 EDT
Ah, issue is already known with vncviewer:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106552
Comment 15 Tim Waugh 2004-09-30 06:50:02 EDT
Mark, I don't think bug #106552 applies except when vncviewer is run
in full-screen -- so we're back to: how can you avoid this when in
full-screen mode?
Comment 16 Ray Strode [halfline] 2004-11-03 11:07:15 EST
*** Bug 129055 has been marked as a duplicate of this bug. ***
Comment 17 Peter Åstrand 2005-01-09 13:38:31 EST
Since I'm working both on rdesktop and VNC, I would be glad if we
could resolve these issues once and for all. Some comments:

jwz wrote:

>I don't know why you say that a "full screen program" must grab the
>keyboard: that's completly untrue!  Grab the focus, perhaps, but not
>the keyboard.  

If the application doesn't grab the keyboard, all WM shortcuts like
Alt-Tab, Alt-F4 etc will be active. This is not what users expect.
I've tried the "fixed" GQView (1.5.6), and it behaves exactly like
this. This is wrong, IMHO. 

With applications like vncviewer and rdesktop, the need for catching
WM keys like Alt-Tab etc is even greater. A "solution" which does not
make this possible is not a solution, IMHO. 

>There is no way to work around this in xscreensaver: rdesktop must be
>fixed instead.   

I don't think this is true. After all, "xlock" causes no problems!
Apparently it creates it's window and gives it focus *before* trying
to grab the keyboard. rdesktop releases the grab as soon as it loses
focus. 

Why cannot xscreensaver use this approach?

So, the policy should then be:

* Applications (for example, rdesktop) should be able to grab the
keyboard, as long as they have the focus. This applies to both
fullscreen and non-fullscreen mode. 

* If some application (like xscreensaver) wishes to "take over" the
grab, it should first take over the focus. 

Comments?
Comment 18 Jamie Zawinski 2005-01-09 16:19:35 EST
I don't know what your comment about xlock means.  First of all, xlock
only locks the screen when the user explicitly activates it, so
presumably in that case, they'd have to have moved the mouse of out
VNC or whatever to go to a unix shell and type "xlock" at it.  

Second, the xlock software is generally broken and ignorant of
security (xlock's brokenness is the reason that xscreensaver exists)
so arguments along the lines of "xlock does it, why don't you"
generally don't hold much weight with me unless accompanied by a
detailed analysis.

Third, and more to the point, a program like xscreensaver cannot
interact with focus, because it uses an override-redirect window.
O-R windows are invisible to the window manager, and cannot be focus
targets at all.  For an O-R window to receive input, it must grab the
keyboard and mouse; there's no other way.


So, VNC has two problems, that it is trying to solve by grabbing the
keyboard on EnterNotify:

   1: the window manager does not give it all keys (Alt-Tab, etc)
   2: the X server does not give it all keys (Alt-F1, C-Alt-BS, etc)

Like markmc said, I think that you should solve #1 with some new
WM-protocol.  This would be useful for many other programs too, for
example, games, and emacs.

I don't think that grabbing the keyboard solves #2 at all, because I
think those magic X server key sequences are not overridable (except
by globally turning on DontZap in the server config.)  I think that
without DontZap, Alt-F1 will always switch consoles and C-Alt-BS will
always kill the server, regardless of grabs.  It would be nice to have
a server extension to turn those on and off, and I've been asking for
one for years, but it doesn't exist yet (e.g., xscreensaver would like
to disable VT switching only while locked.)


Also, a question: why are you grabbing the keyboard in response to
EnterNotify instead of in response to FocusIn?  It seems to me that
this mixes up the "point to type" and "click to type" models, making
VNC always behave as a "point to type" app even when the user has
chosen to use a "click to type" window manager.
Comment 19 Peter Åstrand 2005-01-10 05:04:56 EST
>I don't know what your comment about xlock means.  First of all, xlock
>only locks the screen when the user explicitly activates it, so
>presumably in that case, they'd have to have moved the mouse of out
>VNC or whatever to go to a unix shell and type "xlock" at it.

There's a program called "xautolock" that can activate xlock after
some idle time. For testing purposes, a "sleep 5; xlock" is also
sufficient. 

>Third, and more to the point, a program like xscreensaver cannot
>interact with focus, because it uses an override-redirect window.
>O-R windows are invisible to the window manager, and cannot be focus
>targets at all.  For an O-R window to receive input, it must grab the
>keyboard and mouse; there's no other way.

This is news to me. Where can I found information about this? Is it in
 the Xlib documentation? Do you mean that XSetInputFocus() will fail
for an O-R window?

>So, VNC has two problems, that it is trying to solve by grabbing the
>keyboard on EnterNotify:
>
>   1: the window manager does not give it all keys (Alt-Tab, etc)
>   2: the X server does not give it all keys (Alt-F1, C-Alt-BS, etc)

I don't think case 2 is much of a problem. Also, it has little to do
with the fullscreen and keyboard grab issues. So let's concentrate on
case 1. 

>Like markmc said, I think that you should solve #1 with some new
>WM-protocol.  This would be useful for many other programs too, for
>example, games, and emacs.

A new WM protocol would probably work, but this solution has lot's of
drawbacks: We need to define the protocol, all WMs would need to
implement it, and then all applications would need support. It would
take many years before things would start working. 

>Also, a question: why are you grabbing the keyboard in response to
>EnterNotify instead of in response to FocusIn? 

You mean in rdesktop? Don't know, I haven't written that part. 
Comment 20 Jamie Zawinski 2005-01-10 05:59:17 EST
> This is news to me. Where can I found information about this?

Inter Client Communication Manual section 4.1.10.
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.10

    [...] the client can set override-redirect on the window.
    In general, this should be done only if the pointer is
    grabbed while the window is mapped. The window manager will
    never interfere with these windows, which should be used
    with caution.

    [...] The user will not be able to move, resize, restack,
    or transfer the input focus to override-redirect windows,
    since the window manager is not managing them.  If it is
    necessary for a client to receive keystrokes on an
    override-redirect window, either the client must grab the
    keyboard, or the client must have another top-level window
    that is not override-redirect and that has selected the
    Locally Active or Globally Active focus model.  The client
    may set the focus to the override-redirect window when the
    other window receives a WM_TAKE_FOCUS message or one of the
    events listed in section 4.1.7 in the description of the
    Globally Active focus model.

This says "you can only set (non-grabbed) focus to an
override-redirect window if there is some other (managed, non-O-R)
window that the window manager has already chosen to give focus to."  

Note that, even for *managed* windows, there's no guarantee that the
WM will obey any given client's XSetInputFocus request.  It's a
request, not an order.  For example, if a window manager has a strict
"point to type" policy, and some app that is not under the mouse asks
for focus, the WM may legitimately choose to ignore that, and leave
focus where the mouse is. 

When you try to set focus on a window, and it's a window that the WM
*does not manage* then it's even less likely to obey the request.  The
WM was never sent MapRequest events for the O-R windows, so it has no
internal record of those windows existing at all.  It is unable to
control when they are mapped, unmapped, and resized; it is unable to
decorate them with a title bar; and so it generally won't bother
trying to direct focus to them either.

See also 4.2.7, http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.7

> A new WM protocol would probably work, but this solution has lot's
> of drawbacks

Yes, but it also has the advantage that it's the only possible
solution that will work, if you insist on receiving those keys.

Personally, I prefer the solution of, "you can't have those keys. 
Deal with it."  (Or the corollary, "if you want any app to have those
keys, then configure your window manager to not grab them in the first
place."  For example, since I'm an emacs user, I don't let my WM steal
Alt-Tab.)

> You mean in rdesktop? Don't know, I haven't written that part. 

Well, I think that behavior is probably wrong.  Perhaps you could get
whoever did make that decision to comment on their reasoning?
Comment 21 Mark McLoughlin 2005-01-11 04:11:47 EST
My short term suggestions would be:

  1) Don't grab the keyboard on EnterNotify, do it on FocusIn

  2) Only do this in fullscreen mode

Then start thinking about longer term ways to fix this properly.
Comment 22 Peter Åstrand 2005-01-13 08:11:25 EST
>This says "you can only set (non-grabbed) focus to an
>override-redirect window if there is some other (managed, non-O-R)
>window that the window manager has already chosen to give focus to."

Well, "can" is relative. It's a well known fact that
override-redirect-type fullscreen violates ICCCM in any case. In
practice, you *can* use XSetInputFocus() on a O-R window. Many
fullscreen apps does this. This includes the TightVNC vncviewer. 

>Note that, even for *managed* windows, there's no guarantee that the
>WM will obey any given client's XSetInputFocus request.  It's a
>request, not an order.  For example, if a window manager has a strict
>"point to type" policy, and some app that is not under the mouse asks
>for focus, the WM may legitimately choose to ignore that, and leave
>focus where the mouse is.

You seem to think that the WM keeps the focus state. This is not true;
input focus is a server thing. The WM might try to "fight back",
though, but as far as I know, doing a XSetInputFocus(O-R-window)
guarantees that the active window recieves at least one FocusOut event. 


>> A new WM protocol would probably work, but this solution has lot's
>> of drawbacks
>
>Yes, but it also has the advantage that it's the only possible
>solution that will work, if you insist on receiving those keys.

Keyboard grabs works. The only piece missing is a policy for how one
fullscreen app should tell another that it should give up the grab.
Releasing the grab on FocusOut actually seems to work. I've written
some test code, and it seems to work great. The approach has several
advantages. For example, a screensaver-like program looks just like
any other fullscreen app. It's possible to start multiple fullscreen
apps: The last app started with get the grab, and when this app is
finished, the first fullscreen app will get the focus again (the
second app does XSetInputFocus to the first app on exit). 

There's only one problem with this approach: It breaks when you are
trying to mix fullscreen and ordinary windows. If an ordinary window
gets active and is then closed, the WM will revert the focus to some
other WM-managed window. Not the fullscreen O-R window. 

One way of handling this is to change the policy slightly: Never give
up the grab to a non-O-R window. This would make it impossible to mix,
but at least the user won't be stuck with a fullscreen app that
doesn't accept keyboard input. 

The problem above is one example of the inherit problems with
override-redirect toplevel windows. Wouldn't it be nice if we could
have fullscreen apps without using override-redirect?, I though. Then
I discovered _NET_WM_STATE_FULLSCREEN. Using it in combination with
grabbing the keyboard (for those who need/want), but only when the app
has focus, should solve our problem. 

Or can anyone find a reason why this would *not* work?

Again, it would be really nice with a Fullscreen HOWTO...
Comment 23 Bill Nottingham 2006-08-04 23:53:39 EDT
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Comment 24 Peter Åstrand 2006-08-05 13:41:57 EDT
I don't know what NEEDINFO_REPORTER means, but as far as I know, the problem
exists in all later versions of rdesktop, including the 1.5.0 beta, so probably,
this bug should be kept open and moved to FC5/FC6. 
Comment 25 Bug Zapper 2008-04-03 11:29:39 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 26 Bug Zapper 2008-05-06 19:57:02 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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