Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

window resizing should not be allowed under readonly mode #2137

Closed
totaam opened this issue Feb 6, 2019 · 4 comments
Closed

window resizing should not be allowed under readonly mode #2137

totaam opened this issue Feb 6, 2019 · 4 comments
Labels

Comments

@totaam
Copy link
Collaborator

totaam commented Feb 6, 2019

Issue migrated from trac ticket # 2137

component: core | priority: major | resolution: worksforme | keywords: readonly dimension

2019-02-06 14:54:56: thiner created the issue


From #2136

Logic problem: Under --readonly=yes mode, the window is resizable and resizing of window CHANGED the desktop dimension of server.

To replicate the problem: Open two clients (--sharing=yes), one with readonly=yes. Resize the --readonly=yes window, the other window also has its size changed.

I am not very familiar with ACL of xpra since I have known it for no more than several hours (:p), and I am not sure whether --readonly=yes is security critical. Anyway this can be deemed as a bug.

@totaam
Copy link
Collaborator Author

totaam commented Feb 6, 2019

the window is resizable and resizing of window CHANGED the desktop dimension of server

I assume you mean that the server-side window got resized, and this is then propagated to the other client. The desktop dimension of the server (the xvfb size) is not affected by window resizing.

We need to:

  • server should probably tell the client it is running in readonly mode rather try to cook all the window size-constraint metadata packets
  • client should make all windows non-resizable in readonly mode - bearing in mind that this may affect their appearance (removing handles, removing buttons from the title bar, etc)
  • reject the move and resize part of configure packets from the client when in readonly mode - but still keep track of where the client has mapped the window (since we can't prevent the client OS from moving windows)
  • some client-side window managers may still force resize the window... in this case, not sure what to do

@totaam
Copy link
Collaborator Author

totaam commented Feb 7, 2019

2019-02-07 00:46:23: thiner commented


A readonly client can just be forced to open a flag fit-to-window where all resizing of window only scale the client side view, rather than resizing the master window. :D

@totaam
Copy link
Collaborator Author

totaam commented Feb 7, 2019

A readonly client can just be forced to open a flag fit-to-window where all resizing of window only scale the client side view, rather than resizing the master window. :D

What you describe here is the same as your other ticket: #2136
Now I realize that the same applies to this ticket and that you are also using "shadow" or "start-desktop" here.

So when I said:

The desktop dimension of the server (the xvfb size) is not affected by window resizing.

That is not true of "start-desktop" servers, where we do resize the xvfb size to match the client's window size.

And this one is actually easier to solve for desktop mode.

@totaam
Copy link
Collaborator Author

totaam commented Apr 23, 2019

  • r22524 enforce the readonly flag server-side: clients are told the windows are fixed size and requests to resize them are ignored
  • r22525 does the same thing client-side, r22527 plugs some holes

The problem with the client side is that window managers are free to ignore the hints we give them.. We try our best, but this is going to be very hard to get working perfectly.

@thiner: does that work well enough for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant