search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
543 stars 48 forks source link

Make default screensaver configurable in Qubes global preferences (qubes-prefs) #9049

Open ben-grande opened 8 months ago

ben-grande commented 8 months ago

How to file a helpful issue

Qubes OS release

R4.2

Brief summary

I tried to reproduce on Xfce with XScreensaver but couldn't, but there is a catch with Xfce, Xscreensaver and Dunst: If I lock the screen before dunst sees the message, dunst can't send any more messages/notifications to the user. This happens when using Signal-Desktop with Dunst. Dunst has to be restarted to start showing messages again (systemctl --user restart dunst), not a good usability. dunstctl is-paused always returns false, even though it stops sending notifications. Stopping the user service and running with dunst -verbosity debug, I see INFO: X11: Hiding window, the notifications are received but the notification popup is never shown again unless the daemon is restarted.

The daemon xfce4-notifyd running in a qube can also bypass SDDM lockscreen. It canoot bypass the xscreensaver from my tests. This does not say xscrensaver is immune to this. The xscreensaver FAQ also warns about pop-ups over the screensaver. So this is not a notification daemon problem, as it happens with xfce4-notifyd and dunst. It happens with SDDM (KDE).

This is a problem with X11 and Wayland, as a user on Sway reported to dunst project.

Xfce is probably not gonna support Wayland ever or anytime soon. Move to another DE seems inevitable. Does not mean Wayland is immune also.

I don't think a centralized tray would solve this issue:

The Dom0/GUIVM notification server can not enforce that a notification always goes through them, it can try to redirect, but the DomU can try to skip it.

I understand this may be considered a screenlocker/screensaver issue instead of Qubes, which currently only happens with SDDM (Xscreensaver is not immune to this, but couldn't reproduce), but in the best case scenario, the Qubes-guid can hide windows while the screenlock is activated, else Signal messages with contact profile pictures and contents will be shown to the lock screen, but could be from any application with any kind of sensitive information.

On Qubes with KDE, running notify-send from Dom0 and locking the screen before the notification is sent ( delayed with sleep), the notification does not appear on the locked screen, it only appears after the screen is unlocked.

I may be wrong, but with these tests, I came to the conclusion that it is the way that Qubes-guid interprets DomU window popups, as Dom0 notifications are not affected.

Steps to reproduce

  1. Install KDE and enable SDDM.
  2. Logout of Xfce session and login to Plasma (X11)
  3. Install dunst in an Template and boot an app qube based on it
  4. Send a message to the dunst server: dunstify Hey
  5. Now run the following and lock the screen before the notification appears: sleep 8 && dunstify Hey
  6. See message with the locked screen

In the example I use dunstify, but you can use notify-send also. You can also use xfce4-notifyd as the server instead of dunst and the problem still ocurrs.

Expected behavior

Dom0 filters any popups when screen is locked using qubes-guid.

Actual behavior

Notifications appears with locked screen.

ben-grande commented 8 months ago

Also, all fine if this issue is closed as invalid, as the Qubes GUI is not supposed to take the place of the screenlock, but would be nice if it could prevent these kind of mistakes from happening in the screenlock. Although big issues with screenlock can't be fixed by the GUI, such as showing momentarily the screen when waking up locked.

ben-grande commented 8 months ago

Forgot to mention, such thing was not happening on R4.1, at least, I only noticed on R4.2. Could be due to Plasma version, but I don't have a machine on R4.1 to be able to test.

marmarek commented 8 months ago

qubes-guid has a feature to place windows below a locked screen already. It's configurable via command line and defaults to xscreensaver. We also have an openQA test for this I guess some other value is needed under SDDM.

ben-grande commented 8 months ago

Thanks for the detailed response with links!

Can this issue be converted to: Make default screensaver configurable fir qubes global preferences (qubes-prefs)?

qubes-guid is started by qvm-start-daemon, because of the way it is started, qubes-guid arguments are always the default, is this correct?

qvm-start-daemon has some functions to handle KDE differently, maybe it can enforce the xcreensaver of KDE to be SDDM?

Using Xscrensaver with KDE is possible but apparently requires editing a bunch of settings that may be lost on package upgrades.

We also have an openQA test for this I guess some other value is needed under SDDM.

Yeah, understandably as the tests only seem to occur on Xfce, this KDE issue wasn't noticed.