-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
RFD 51: X11 forwarding #10009
RFD 51: X11 forwarding #10009
Conversation
e1b56dd
to
35220e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor comments, but LGTM.
69a7198
to
c3ff6d5
Compare
@zmb3 please take another look, I made significant changes to the UX and security sections. |
or other sources to discover the reason, and personally decide whether to switch to `trusted` | ||
forwarding or keep their X Server secure. | ||
|
||
This does leave us with the unfortunate fact that the UX of `tsh` and `ssh` will be different |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this became a problem, we could technically add some code to detect if tsh
is aliased and being invoked as ssh
, and supporting the ssh
flags only in that case.
Right?
@Joerger Do we have any plans to add audit to X11 sessions? I'm not sure if this even possible, but technically having that enabled allows you to run X11 session and do some stuff that goes "under the radar" of our auditing. |
The X11 session is logged in the audit log, but the X11 session is not currently being recorded, I assume that's what you're referring to. It's true that a user could do something like this, such as something simple like opening This might be possible but hasn't been requested/discussed yet, and we've decided to skip it for the MVP. But when/if we do it, we'd basically have to tee the byte stream from the X Server Proxy to a session log. Then that byte stream could be sent to the player's |
Current implementation - #9897