Bug 429857 - Allow to whitelist apps that can stay ontop of the screen lock
Summary: Allow to whitelist apps that can stay ontop of the screen lock
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (other bugs)
Version First Reported In: 5.20.3
Platform: Other Other
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-30 17:19 UTC by Jim Jones
Modified: 2024-06-15 17:32 UTC (History)
3 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 Jim Jones 2020-11-30 17:19:43 UTC
SUMMARY


STEPS TO REPRODUCE
1. while list app like mpv
2. lock screen
3. app/mpv stays ontop
Comment 1 Zamundaaa 2024-06-07 17:30:26 UTC
Sorry, but this would circumvent the purpose of the lock screen and poses additional security risks, without really changing usability. I don't think this should be implemented
Comment 2 Pedro V 2024-06-15 17:32:20 UTC
Now this is what could be an XY problem, at least I believe I see what's the basic desire which is quite reasonable, but instead of that being described, a not really great potential solution was pitched instead.

There are multiple forms of the generic idea, but it's all based on the problem of locking being all or nothing. There are some program-specific "layers" like password managers having separate locking, but there's no generic solution for allowing partial access to the system with seamless switching to full/different access.

I'm not up to date on the topic, but consider some already existing solutions:
- Android offers "app pinning" which is possibly the closest to what the user desires. A program can be "pinned" which makes it usable while the system itself is locked, so the device can be handed over to others, giving access to just a single program.
- Android offers various forms of "secure containers" which is somewhat all over the place, but the general idea is having another layer of security to access specific programs. The implementations tend to be quite odd, but this tends to have the seamless desire as "secure" programs appear just like others once unlocked.
- Multiple different operating systems are multi-user to some degree, so there's typically some kind of user switching. Currently on Linux at least sound is handled weirdly as PipeWire is user-level so audio setup is torn down during switching which is not handled by all programs too well, and it's generally not really a seamless process.

It's likely still early to have related desires, but back when I've seen early multi-seat discussions about Wayland, one of the possible use cases I envisioned is quite relevant.
The privilege separation part is tricky so I'll leave parts up to imagination, but it would be great if a single Wayland session could contain multiple different security contexts. Going with the reporter's simple desire, if mpv was started with a separate not really privileged user, then it would be great if the privileged user's session could be locked making its windows disappear, but the mpv window from the unlocked user would be still around.

One user per monitor is a lower bar that used to be possible, and it could be a good enough solution given enough flexibility like "roaming" mouse and the ability to easily move a session from one monitor to another, but given that this direction mostly regressed, I'm not expecting such features any soon. Some relevant links:
Bug 416720
Bug 256242
https://wiki.archlinux.org/title/xorg_multiseat