Bug 331134 - clipboard content is shared between users in Xorg multiseat mode
Summary: clipboard content is shared between users in Xorg multiseat mode
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kde
Classification: I don't know
Component: clipboard (other bugs)
Version First Reported In: 4.11.5
Platform: Kubuntu Linux
: NOR critical
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-14 11:42 UTC by Colin
Modified: 2020-09-09 03:16 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Colin 2014-02-14 11:42:57 UTC
When running a system in multiseat mode with 2 or more X sessions (each X session is logged in as a different user, using separate monitors and separate video cards in the system), content copied onto the clipboard in KDE is accessible to all users on the system regardless of user permissions (e.g. unprivileged user can access clipboard of admin level user). This can be a huge security flaw as users can have access to each others private content.

Reproducible: Always

Steps to Reproduce:
1. Start Xorg in multiseat mode
2. Login to KDE in different user accounts for each X session
3. copy text as user in first seat
4. paste text as user in second seat to get first users clipboard content
Actual Results:  
Can access clipboard content of other users on system.

Expected Results:  
Users only should have access to their own clipboard content.

System is running Kubuntu 13.10 with lightdm in multiseat mode. 

Marked as critical because this bug causes you to lose data to other users, and I believe it can be a huge security issue if one user copies sensitive information and he believes this information will not be accessible to other users on the system.
Comment 1 Christoph Feck 2014-02-14 18:53:29 UTC
> e.g. unprivileged user can access clipboard of admin level user

Wouldn't that mean there is a hole in X11? Maybe intended? How do other desktops behave or how do they avoid this issue? Does it still happen, if you do not use Klipper?
Comment 2 Colin 2014-02-14 19:19:45 UTC
(In reply to comment #1)
> > e.g. unprivileged user can access clipboard of admin level user
> 
> Wouldn't that mean there is a hole in X11? Maybe intended? How do other
> desktops behave or how do they avoid this issue? Does it still happen, if
> you do not use Klipper?

This behaviour is present with and without Klipper (which does store and display the entire copy history of all users to each other) being present. I am not sure if it may be related to something in X11, I thought the copy paste functionality was implemented at the desktop environment level (KDE). I haven't had the chance to test this in other desktop environments yet as the system I discovered this on only has KDE installed at the moment. 

It does not make sense to me that this behaviour would be intended, user accounts are blocked from interacting with each other in other ways without permissions (i.e. you cannot browse to other users home folder, change their settings etc.), why should they have access to the other users copy history?
Comment 3 Andrew Crouthamel 2018-11-11 04:27:33 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Andrew Crouthamel 2018-11-21 04:45:18 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Nate Graham 2020-09-09 03:16:21 UTC
No response; closing.