Qubes-specific preconfiguration for Xfce4

[rootkovska]

I'd like to see a few tweaks to the default Xfce4 configuration we will offer for Qubes OS:

1. Ensure the screen gets locked when the system is suspended to S3. By default this is not the case. As tested on two different machines, ticking of "Lock screen when system is going for sleep" in the Xfce Power Manager/System Tab has no effect. In order to enforce screen locking before S3 sleep, one needs to (additionally?) also tick "Lock screen before sleep" in the "Session and Startup" settings pane of the Xfce4.
2. It seems one can get rather effective focus stealing prevention in Xfce by unticking "Automatically give focus to newly created windows" in the "WIndow Manager" pane, Focus tab. Interestingly there is also "Activate focus stealing prevention" option in the "Window Manager Tweaks" pane's Focus tab. I haven't tested it, and could find any description how it is expected to work. I keep it disabled, FWIW.
3. Xfce offers a number of WM and widgets themes. From the Qubes-point of view, we should use the theme that makes titlebars look readable even for yellow or gray windows (and at the same time for dark-colored ones). I personally like the combination of "Agualemon" for the WM (Window Manager/Style), and the "Clearlooks" theme (Appearance/Style).

Ideally we could use Salt to enforce the above (and I'm sure many other) customizations?

[marmarek]

Suggestion from Niels Kobschätzki: install xfce4-whiskermenu-plugin

[marmarek]

Suggestion from Niels Kobschätzki: install xfce4-whiskermenu-plugin

[micahflee]

I'm also running into a problem where when I close my laptop lid, my computer doesn't suspend. In Power Manager, General, under Laptop Lid I have "When laptop lid is closed" set to "Suspend" for both on battery and while plugged in. but it doesn't seem to work. Instead when I close the lid, nothing happens, and the screen doesn't even lock.

[micahflee]

I'm also running into a problem where when I close my laptop lid, my computer doesn't suspend. In Power Manager, General, under Laptop Lid I have "When laptop lid is closed" set to "Suspend" for both on battery and while plugged in. but it doesn't seem to work. Instead when I close the lid, nothing happens, and the screen doesn't even lock.

[marmarek]

@rootkovska I think using salt for this kind of settings isn't good idea. Because it will reset them to those values even if user consciously configured something else. We already have a package for Qubes specific default settings (xfce4-settings-qubes) and it should be the place for such things.

[marmarek]

@rootkovska I think using salt for this kind of settings isn't good idea. Because it will reset them to those values even if user consciously configured something else. We already have a package for Qubes specific default settings (xfce4-settings-qubes) and it should be the place for such things.

[marmarek]

What should be default for lid close? Suspend or just screen lock?

[marmarek]

What should be default for lid close? Suspend or just screen lock?

[rootkovska]

On Mon, Jul 11, 2016 at 07:21:42AM -0700, Marek Marczykowski-Górecki wrote:

What should be default for lid close? Suspend or just screen lock?

IMHO most ppl expect S3 sleep after lid close. But we need to ensure screen
locker gets engaged first.

[rootkovska]

On Mon, Jul 11, 2016 at 07:21:42AM -0700, Marek Marczykowski-Górecki wrote:

What should be default for lid close? Suspend or just screen lock?

IMHO most ppl expect S3 sleep after lid close. But we need to ensure screen
locker gets engaged first.

[marmarek]

Agualemon WM style results in indistinguishable buttons (close, minimize etc) - because they are all colored in VM label color...

[marmarek]

Agualemon WM style results in indistinguishable buttons (close, minimize etc) - because they are all colored in VM label color...

[rootkovska]

Why do you think that coloring of buttons helps in any way in deducing their meaning? E.g. what color would you expect to suggests a "close" operation vs "maximize"? :)

[rootkovska]

Why do you think that coloring of buttons helps in any way in deducing their meaning? E.g. what color would you expect to suggests a "close" operation vs "maximize"? :)

[marmarek]

Why do you think that coloring of buttons helps in any way in deducing their meaning? E.g. what color would you expect to suggests a "close" operation vs "maximize"? :)

I haven't said that ;) I've said currently they are all the same, so even if originally had different colors (which may or may not help guessing their meaning), now all are the same.

[marmarek]

Why do you think that coloring of buttons helps in any way in deducing their meaning? E.g. what color would you expect to suggests a "close" operation vs "maximize"? :)

I haven't said that ;) I've said currently they are all the same, so even if originally had different colors (which may or may not help guessing their meaning), now all are the same.

[rootkovska]

Actually I see they have different shades ;) I'm more concerned that black-labeled windows are indistinguishable from gray-labeled ones. Sadly this seems to be the case for most (all) decorations in Xfce4 I looked at (which do not look somehow ugly at the same time).

[rootkovska]

Actually I see they have different shades ;) I'm more concerned that black-labeled windows are indistinguishable from gray-labeled ones. Sadly this seems to be the case for most (all) decorations in Xfce4 I looked at (which do not look somehow ugly at the same time).

[marmarek]

I'm more concerned that black-labeled windows are indistinguishable from gray-labeled ones.

Same here, since forever. Colors are defined here:
https://github.com/QubesOS/qubes-desktop-linux-xfce4/blob/master/xfwm4/xfwm4-4.12.3-qubes-decoration.patch#L985-L994

Can you spot what is wrong?

[marmarek]

I'm more concerned that black-labeled windows are indistinguishable from gray-labeled ones.

Same here, since forever. Colors are defined here:
https://github.com/QubesOS/qubes-desktop-linux-xfce4/blob/master/xfwm4/xfwm4-4.12.3-qubes-decoration.patch#L985-L994

Can you spot what is wrong?

[marmarek]

Anyway, what default window style do you propose?

[marmarek]

Anyway, what default window style do you propose?

[micahflee]

I'm currently using "Sassandra" and I think it looks good. The maximize/minimize/quit icons have distinguishable icons regardless of the color.

[micahflee]

I'm currently using "Sassandra" and I think it looks good. The maximize/minimize/quit icons have distinguishable icons regardless of the color.

[marmarek]

I think I've found why black is the same as gray - our patched theme loading function use very similar algorithm to icon coloring - convert color to HSV, then use H and S from VM label, but V from original theme. This is why button shapes are visible at all.
But for black/gray H and S values are the same...
I'll try how it would look when instead of ignoring V from VM label, it will be multiplied with the value from the theme. But probably not much better - especially black will still be gray, just slightly different share od gray than the gray label.

[marmarek]

I think I've found why black is the same as gray - our patched theme loading function use very similar algorithm to icon coloring - convert color to HSV, then use H and S from VM label, but V from original theme. This is why button shapes are visible at all.
But for black/gray H and S values are the same...
I'll try how it would look when instead of ignoring V from VM label, it will be multiplied with the value from the theme. But probably not much better - especially black will still be gray, just slightly different share od gray than the gray label.

[marmarek]

As for screen locking and system suspend - there are two factors:

• who initiate system suspend - it can be either xfce4-power-manager or systemd/logind
• who initiate screen locking

The first one is especially interesting for lid close action. Xfce4-power-manager supports both options - either handle it itself or delegate to logind. There is an option for this (xfconf-query -c xfce4-power-manager /xfce4-power-manager/logind-handle-lid-switch).
When set to false it's all good - screen is locked according to appropriate setting - by calling xflock4 from xfce4-power-manager (which triggers xscreensaver), system is suspended on lid close. But when set to true, lid close is handled by logind, and then screen isn't properly locked because xscreensaver doesn't support logind interface for triggering screen lock.

In theory the solution would be to set that property to false and done. But in practice, xfce4-power-manager-settingshas hardcoded logic to switch it totruefor combination of screen lock + suspend on lid close. Comment in code says it's forlight-lockerintegration (just another screen locker, compatible withlightdm` session manager).

So I see those options:

• patch xfce4-power-manager-settings to not mess with logind-handle-lid-switch option
• use light-locker or other logind compatible screen locker
• use some proxy to trigger xscreensaver when logind ask for it - for example xss-lock

I think the last option would be the best, as gives flexibility on screenlocker choice and IMHO is most resilient against breaking screen lock by messing configuration (like switching logind-handle-lid-switch or changing used screen locker software).

[marmarek]

As for screen locking and system suspend - there are two factors:

• who initiate system suspend - it can be either xfce4-power-manager or systemd/logind
• who initiate screen locking

The first one is especially interesting for lid close action. Xfce4-power-manager supports both options - either handle it itself or delegate to logind. There is an option for this (xfconf-query -c xfce4-power-manager /xfce4-power-manager/logind-handle-lid-switch).
When set to false it's all good - screen is locked according to appropriate setting - by calling xflock4 from xfce4-power-manager (which triggers xscreensaver), system is suspended on lid close. But when set to true, lid close is handled by logind, and then screen isn't properly locked because xscreensaver doesn't support logind interface for triggering screen lock.

In theory the solution would be to set that property to false and done. But in practice, xfce4-power-manager-settingshas hardcoded logic to switch it totruefor combination of screen lock + suspend on lid close. Comment in code says it's forlight-lockerintegration (just another screen locker, compatible withlightdm` session manager).

So I see those options:

• patch xfce4-power-manager-settings to not mess with logind-handle-lid-switch option
• use light-locker or other logind compatible screen locker
• use some proxy to trigger xscreensaver when logind ask for it - for example xss-lock

I think the last option would be the best, as gives flexibility on screenlocker choice and IMHO is most resilient against breaking screen lock by messing configuration (like switching logind-handle-lid-switch or changing used screen locker software).

[rootkovska]

1. Can we easily test this light-locker screensaver? I'd love to replace Xscreensaver. Because ugly :)
2. I'm somehow skeptical about us creating this proxy-based workaround. Suspect we might e.g run into some race conditions, which might end up with the screen not being locked correctly? Also, seems like more work in the name of... flexibility that won't be used by 99% of users anyway (and those would like to, would be using a different WM anyway, I suspect).

[rootkovska]

1. Can we easily test this light-locker screensaver? I'd love to replace Xscreensaver. Because ugly :)
2. I'm somehow skeptical about us creating this proxy-based workaround. Suspect we might e.g run into some race conditions, which might end up with the screen not being locked correctly? Also, seems like more work in the name of... flexibility that won't be used by 99% of users anyway (and those would like to, would be using a different WM anyway, I suspect).

[rootkovska]

On Tue, Jul 12, 2016 at 02:59:54PM -0700, Marek Marczykowski-Górecki wrote:

I think I've found why black is the same as gray - our patched theme loading function use very similar algorithm to icon coloring - convert color to HSV, then use H and S from VM label, but V from original theme. This is why button shapes are visible at all.
But for black/gray H and S values are the same...
I'll try how it would look when instead of ignoring V from VM label, it will be multiplied with the value from the theme.

Perhaps an ugly hack like e.g.:

if (label == QUBES_LABEL_BLACK) v = orig_v * 0.1 // or similarly low factor?

Because other colors look really nice and we don't want to break them

Sure, it's inelegant, but using this reasoning, we find that with current
HSV-based code also the definitions of GRAY and BLACK are inelegant (as they are
not colors, according to the HSV model).

[rootkovska]

On Tue, Jul 12, 2016 at 02:59:54PM -0700, Marek Marczykowski-Górecki wrote:

I think I've found why black is the same as gray - our patched theme loading function use very similar algorithm to icon coloring - convert color to HSV, then use H and S from VM label, but V from original theme. This is why button shapes are visible at all.
But for black/gray H and S values are the same...
I'll try how it would look when instead of ignoring V from VM label, it will be multiplied with the value from the theme.

Perhaps an ugly hack like e.g.:

if (label == QUBES_LABEL_BLACK) v = orig_v * 0.1 // or similarly low factor?

Because other colors look really nice and we don't want to break them

Sure, it's inelegant, but using this reasoning, we find that with current
HSV-based code also the definitions of GRAY and BLACK are inelegant (as they are
not colors, according to the HSV model).

[marmarek]

Can we easily test this light-locker screensaver? I'd love to replace Xscreensaver. Because ugly :)

1. Sure - install light-locker package in dom0.
2. Make sure you use LightDM, not anything else (like KDM). In Xfce4-only installation it should be default. If not, execute:

systemctl disable kdm
systemctl enable lightdm
reboot

(or instead of reboot, switch to text console, stop kdm, start lightdm and login again - this will preserve running VMs and applications)

I'm somehow skeptical about us creating this proxy-based workaround. Suspect we might e.g run into some race conditions, which might end up with the screen not being locked correctly? Also, seems like more work in the name of... flexibility that won't be used by 99% of users anyway (and those would like to, would be using a different WM anyway, I suspect).

It isn't us creating such proxy - it already exists. It's very similar to the first case - matter of installing xss-lock and starting it (on session startup) like this: xss-lock xflock4.
According to documentation:

• The login manager can also request that the session be locked; as a result of
  loginctl lock-sessions, for example. Additionally, xss-lock uses the
  inhibition logic to lock the screen before the system goes to sleep.

So, no more short original screen view after system wakeup (which was the case on KDE...). But the same should be apply to light-locker too.

BTW As for aesthetics, I very much like default screen locker for i3 - i3lock. You can try it simply by installing this package and starting it manually. I recommend black background: i3lock -c 000000. But since there is no "Enter password:" message on the screen, probably it isn't good for normal users.

[marmarek]

Can we easily test this light-locker screensaver? I'd love to replace Xscreensaver. Because ugly :)

1. Sure - install light-locker package in dom0.
2. Make sure you use LightDM, not anything else (like KDM). In Xfce4-only installation it should be default. If not, execute:

systemctl disable kdm
systemctl enable lightdm
reboot

(or instead of reboot, switch to text console, stop kdm, start lightdm and login again - this will preserve running VMs and applications)

I'm somehow skeptical about us creating this proxy-based workaround. Suspect we might e.g run into some race conditions, which might end up with the screen not being locked correctly? Also, seems like more work in the name of... flexibility that won't be used by 99% of users anyway (and those would like to, would be using a different WM anyway, I suspect).

It isn't us creating such proxy - it already exists. It's very similar to the first case - matter of installing xss-lock and starting it (on session startup) like this: xss-lock xflock4.
According to documentation:

• The login manager can also request that the session be locked; as a result of
  loginctl lock-sessions, for example. Additionally, xss-lock uses the
  inhibition logic to lock the screen before the system goes to sleep.

So, no more short original screen view after system wakeup (which was the case on KDE...). But the same should be apply to light-locker too.

BTW As for aesthetics, I very much like default screen locker for i3 - i3lock. You can try it simply by installing this package and starting it manually. I recommend black background: i3lock -c 000000. But since there is no "Enter password:" message on the screen, probably it isn't good for normal users.

[marmarek]

Perhaps an ugly hack like e.g.: if (label == QUBES_LABEL_BLACK) v = orig_v * 0.1 // or similarly low factor? Because other colors look really nice and we don't want to break them

Or maybe, we should get rid of black/gray label (one of them) and replace with some other very similar (or totally different ;) )? Personally I haven't used gray label ever (because it's the same as black on Xfce ;) ).

[marmarek]

Perhaps an ugly hack like e.g.: if (label == QUBES_LABEL_BLACK) v = orig_v * 0.1 // or similarly low factor? Because other colors look really nice and we don't want to break them

Or maybe, we should get rid of black/gray label (one of them) and replace with some other very similar (or totally different ;) )? Personally I haven't used gray label ever (because it's the same as black on Xfce ;) ).

[rootkovska]

On Wed, Jul 13, 2016 at 01:44:46AM -0700, Marek Marczykowski-Górecki wrote:

Can we easily test this light-locker screensaver? I'd love to replace Xscreensaver. Because ugly :)

1. Sure - install light-locker package in dom0.
2. Make sure you use LightDM, not anything else (like KDM). In Xfce4-only installation it should be default. If not, execute:

systemctl disable kdm
systemctl enable lightdm
reboot

(or instead of reboot, switch to text console, stop kdm, start lightdm and login again - this will preserve running VMs and applications)

The above doesn't seem to be working. Xfce4 seems to prefer xscreensaver anyway.
And if I disable it manually (in Session and Startup/Application Autostart),
then Xfce4 won't screenlock anymore.

I use lightdm, and its service is enabled and running via systemctl.

[rootkovska]

On Wed, Jul 13, 2016 at 01:44:46AM -0700, Marek Marczykowski-Górecki wrote:

Can we easily test this light-locker screensaver? I'd love to replace Xscreensaver. Because ugly :)

1. Sure - install light-locker package in dom0.
2. Make sure you use LightDM, not anything else (like KDM). In Xfce4-only installation it should be default. If not, execute:

systemctl disable kdm
systemctl enable lightdm
reboot

(or instead of reboot, switch to text console, stop kdm, start lightdm and login again - this will preserve running VMs and applications)

The above doesn't seem to be working. Xfce4 seems to prefer xscreensaver anyway.
And if I disable it manually (in Session and Startup/Application Autostart),
then Xfce4 won't screenlock anymore.

I use lightdm, and its service is enabled and running via systemctl.

[marmarek]

The above doesn't seem to be working. Xfce4 seems to prefer xscreensaver anyway.

During suspend? Change lid close action to something else, then back to suspend and close the lid.
Generally, as noted above, there are multiple ways to trigger screen lock. Even during suspend it depends on what initiate the suspend...

The other setting (when screen lock is initiated by some xfce-specific mechanism - namely xflock4), you can set it to use the same as light-locker this way:

xfconf-query -c xfce4-session -p /general/LockCommand -n -t string -s 'loginctl lock-session'

[marmarek]

The above doesn't seem to be working. Xfce4 seems to prefer xscreensaver anyway.

During suspend? Change lid close action to something else, then back to suspend and close the lid.
Generally, as noted above, there are multiple ways to trigger screen lock. Even during suspend it depends on what initiate the suspend...

The other setting (when screen lock is initiated by some xfce-specific mechanism - namely xflock4), you can set it to use the same as light-locker this way:

xfconf-query -c xfce4-session -p /general/LockCommand -n -t string -s 'loginctl lock-session'

[rootkovska]

On Wed, Jul 13, 2016 at 08:38:54AM -0700, Marek Marczykowski-Górecki wrote:

The above doesn't seem to be working. Xfce4 seems to prefer xscreensaver anyway.

During suspend? Change lid close action to something else, then back to suspend and close the lid.
Generally, as noted above, there are multiple ways to trigger screen lock. Even during suspend it depends on what initiate the suspend...

Ok, I didn't realize it would only be used for S3 sleep, and not for ordinary
screen lock (as initiated by e.g. Ctrl-Alt-L, or via menu). This is really silly
to use two difference screen locking programs IMHO.

Another observation: so after I resume from S3 now with using lightdm +
lightlocker (my setem used sddm before, BTW), I observe the following:

1. A quick screen saying something I cannot read, because it disappears too
   quickly. But I guess something like: your screen is locked, redirecting to login
   manager, or something.
2. I can log in via lightdm-like-looking screen
3. I'm finally presented with my X session, but neither keystrokes, nor mouse,
   even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work,
   and mouse cursor moves, but is often not visible. Another S usually helps.
4. All the above takes lots of time.

All in all: a huge regression.

[rootkovska]

On Wed, Jul 13, 2016 at 08:38:54AM -0700, Marek Marczykowski-Górecki wrote:

The above doesn't seem to be working. Xfce4 seems to prefer xscreensaver anyway.

During suspend? Change lid close action to something else, then back to suspend and close the lid.
Generally, as noted above, there are multiple ways to trigger screen lock. Even during suspend it depends on what initiate the suspend...

Ok, I didn't realize it would only be used for S3 sleep, and not for ordinary
screen lock (as initiated by e.g. Ctrl-Alt-L, or via menu). This is really silly
to use two difference screen locking programs IMHO.

Another observation: so after I resume from S3 now with using lightdm +
lightlocker (my setem used sddm before, BTW), I observe the following:

1. A quick screen saying something I cannot read, because it disappears too
   quickly. But I guess something like: your screen is locked, redirecting to login
   manager, or something.
2. I can log in via lightdm-like-looking screen
3. I'm finally presented with my X session, but neither keystrokes, nor mouse,
   even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work,
   and mouse cursor moves, but is often not visible. Another S usually helps.
4. All the above takes lots of time.

All in all: a huge regression.

[marmarek]

This is really silly to use two difference screen locking programs IMHO.

Of course. When we decide on final solution, it needs to be configured for all the cases (manual lock, inactivity lock, manual suspend, lid close suspend).

1. A quick screen saying something I cannot read, because it disappears too quickly. But I guess something like: your screen is locked, redirecting to login manager, or something.

I see this too.

1. I'm finally presented with my X session, but neither keystrokes, nor mouse, even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work, and mouse cursor moves, but is often not visible. Another S usually helps.

It works for me. It it only the case for light-locker?

[marmarek]

This is really silly to use two difference screen locking programs IMHO.

Of course. When we decide on final solution, it needs to be configured for all the cases (manual lock, inactivity lock, manual suspend, lid close suspend).

1. A quick screen saying something I cannot read, because it disappears too quickly. But I guess something like: your screen is locked, redirecting to login manager, or something.

I see this too.

1. I'm finally presented with my X session, but neither keystrokes, nor mouse, even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work, and mouse cursor moves, but is often not visible. Another S usually helps.

It works for me. It it only the case for light-locker?

[marmarek]

if (label == QUBES_LABEL_BLACK) v = orig_v * 0.1 // or similarly low factor?

With 0.1 buttons are totally invisible. But with 0.2 it is ok :)

[marmarek]

if (label == QUBES_LABEL_BLACK) v = orig_v * 0.1 // or similarly low factor?

With 0.1 buttons are totally invisible. But with 0.2 it is ok :)

[rootkovska]

On Wed, Jul 13, 2016 at 02:14:21PM -0700, Marek Marczykowski-G�recki wrote:

This is really silly to use two difference screen locking programs IMHO.

Of course. When we decide on final solution, it needs to be configured for all the cases (manual lock, inactivity lock, manual suspend, lid close suspend).

1. A quick screen saying something I cannot read, because it disappears too quickly. But I guess something like: your screen is locked, redirecting to login manager, or something.

I see this too.

1. I'm finally presented with my X session, but neither keystrokes, nor mouse, even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work, and mouse cursor moves, but is often not visible. Another S usually helps.

It works for me. It it only the case for light-locker?

Yes. And I also have an additional observation after using lightdm +
light-locker:

1. After resume redirected through light-locker/lightdm, the gui agent for my
   debian-8-based VM works no more. I can see a VM windows for a microsecond, then
   they disappear. Verified 2x times already.

I suspect this might be related to this error I see in the guid log:

ErrorHandler: BadValue (integer parameter out of range for operation)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 3 (X_ShmPutImage)
                 Value:        0x2df
                 Failed serial number:  173
                 Current serial number: 174

[rootkovska]

On Wed, Jul 13, 2016 at 02:14:21PM -0700, Marek Marczykowski-G�recki wrote:

This is really silly to use two difference screen locking programs IMHO.

Of course. When we decide on final solution, it needs to be configured for all the cases (manual lock, inactivity lock, manual suspend, lid close suspend).

1. A quick screen saying something I cannot read, because it disappears too quickly. But I guess something like: your screen is locked, redirecting to login manager, or something.

I see this too.

1. I'm finally presented with my X session, but neither keystrokes, nor mouse, even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work, and mouse cursor moves, but is often not visible. Another S usually helps.

It works for me. It it only the case for light-locker?

Yes. And I also have an additional observation after using lightdm +
light-locker:

1. After resume redirected through light-locker/lightdm, the gui agent for my
   debian-8-based VM works no more. I can see a VM windows for a microsecond, then
   they disappear. Verified 2x times already.

I suspect this might be related to this error I see in the guid log:

ErrorHandler: BadValue (integer parameter out of range for operation)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 3 (X_ShmPutImage)
                 Value:        0x2df
                 Failed serial number:  173
                 Current serial number: 174

[rootkovska]

On Thu, Jul 14, 2016 at 09:37:54AM +0200, Joanna Rutkowska wrote:

On Wed, Jul 13, 2016 at 02:14:21PM -0700, Marek Marczykowski-Górecki wrote:

This is really silly to use two difference screen locking programs IMHO.

Of course. When we decide on final solution, it needs to be configured for all the cases (manual lock, inactivity lock, manual suspend, lid close suspend).

1. A quick screen saying something I cannot read, because it disappears too quickly. But I guess something like: your screen is locked, redirecting to login manager, or something.

I see this too.

1. I'm finally presented with my X session, but neither keystrokes, nor mouse, even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work, and mouse cursor moves, but is often not visible. Another S usually helps.

It works for me. It it only the case for light-locker?

Yes. And I also have an additional observation after using lightdm +
light-locker:

1. After resume redirected through light-locker/lightdm, the gui agent for my
   debian-8-based VM works no more. I can see a VM windows for a microsecond, then
   they disappear. Verified 2x times already.

I suspect this might be related to this error I see in the guid log:

ErrorHandler: BadValue (integer parameter out of range for operation)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 3 (X_ShmPutImage)
                 Value:        0x2df
                 Failed serial number:  173
                 Current serial number: 174

Alright, two more comments

1. This affects any new AppVM I want to start after resume from S3 through
   lighdm/loght-locker, not just debian-based.
2. Logging out and logging in again to X session fixes the problem. Until the
   next S3 that is :/

[rootkovska]

On Thu, Jul 14, 2016 at 09:37:54AM +0200, Joanna Rutkowska wrote:

On Wed, Jul 13, 2016 at 02:14:21PM -0700, Marek Marczykowski-Górecki wrote:

This is really silly to use two difference screen locking programs IMHO.

Of course. When we decide on final solution, it needs to be configured for all the cases (manual lock, inactivity lock, manual suspend, lid close suspend).

1. A quick screen saying something I cannot read, because it disappears too quickly. But I guess something like: your screen is locked, redirecting to login manager, or something.

I see this too.

1. I'm finally presented with my X session, but neither keystrokes, nor mouse, even touchpad, do not work for some 5-10 seconds. Later keyboard starts to work, and mouse cursor moves, but is often not visible. Another S usually helps.

It works for me. It it only the case for light-locker?

Yes. And I also have an additional observation after using lightdm +
light-locker:

1. After resume redirected through light-locker/lightdm, the gui agent for my
   debian-8-based VM works no more. I can see a VM windows for a microsecond, then
   they disappear. Verified 2x times already.

I suspect this might be related to this error I see in the guid log:

ErrorHandler: BadValue (integer parameter out of range for operation)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 3 (X_ShmPutImage)
                 Value:        0x2df
                 Failed serial number:  173
                 Current serial number: 174

Alright, two more comments

1. This affects any new AppVM I want to start after resume from S3 through
   lighdm/loght-locker, not just debian-based.
2. Logging out and logging in again to X session fixes the problem. Until the
   next S3 that is :/

[marmarek]

On Thu, Jul 14, 2016 at 12:38:08AM -0700, Joanna Rutkowska wrote:

1. After resume redirected through light-locker/lightdm, the gui agent for my
   debian-8-based VM works no more. I can see a VM windows for a microsecond, then
   they disappear. Verified 2x times already.

I suspect this might be related to this error I see in the guid log:

ErrorHandler: BadValue (integer parameter out of range for operation)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 3 (X_ShmPutImage)
                 Value:        0x2df
                 Failed serial number:  173
                 Current serial number: 174

I think this is unrelated, as I'm just debugging this on the system
which never get to sleep, nor have light-locker installed at all.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Jul 14, 2016 at 12:38:08AM -0700, Joanna Rutkowska wrote:

1. After resume redirected through light-locker/lightdm, the gui agent for my
   debian-8-based VM works no more. I can see a VM windows for a microsecond, then
   they disappear. Verified 2x times already.

I suspect this might be related to this error I see in the guid log:

ErrorHandler: BadValue (integer parameter out of range for operation)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 3 (X_ShmPutImage)
                 Value:        0x2df
                 Failed serial number:  173
                 Current serial number: 174

I think this is unrelated, as I'm just debugging this on the system
which never get to sleep, nor have light-locker installed at all.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Apparently light-locker starts new X server to just host screen locker... This is why it takes so long. And indeed this is related to breaking GUI.

So, I think we should abandon light-locker idea.

The other solution is to launch xss-lock xflock4 which will connect whatever user configured as screen locking program - by default xscreensaver, changeable by:

xfconf-query -c xfce4-session -p /general/LockCommand -n -t string -s 'some locking program'

(not sure if there is GUI for it)
One may want to plug physlock as proposed in #963 (comment)

[marmarek]

Apparently light-locker starts new X server to just host screen locker... This is why it takes so long. And indeed this is related to breaking GUI.

So, I think we should abandon light-locker idea.

The other solution is to launch xss-lock xflock4 which will connect whatever user configured as screen locking program - by default xscreensaver, changeable by:

xfconf-query -c xfce4-session -p /general/LockCommand -n -t string -s 'some locking program'

(not sure if there is GUI for it)
One may want to plug physlock as proposed in #963 (comment)

[marmarek]

Here is some comprehensive list of screen locking applications:
https://wiki.archlinux.org/index.php/List_of_applications/Security#Screen_lockers

[marmarek]

Here is some comprehensive list of screen locking applications:
https://wiki.archlinux.org/index.php/List_of_applications/Security#Screen_lockers

[marmarek]

It seems one can get rather effective focus stealing prevention in Xfce by unticking "Automatically give focus to newly created windows" in the "WIndow Manager" pane, Focus tab.

Yes, it may solve one of the problem: focus stealing by just opening new window (like launching something requiring user confirmation) and having focus there.
But it does not solve the other problems:

• focus stealing by closing the current window.
• focus stealing by launching new window just under mouse cursor (before anticipated click) - which includes also convincing the user to click in particular place (for example using a simple game...).

In the first case, if someone want to fool user into confirming some action, the attacker needs to predict when user will press enter, then:

1. Launch the action (which will result in confirmation dialog)
2. Close the current window

You can try this by opening terminal, then launching gnome-terminal & exit. The new terminal window will receive focus. Without this option enabled, exit is not needed.

So, in practice this option make the attack only slightly harder, but IMHO makes normal usage much more annoying. Like if I open new window (like "file->open" dialog via Ctrl-O in some application), I need to do additional action (switch focus - one click, or Alt-tab) to do the task. Every time.

I think the ultimate solution for focus stealing in qrexec confirmations is to force some delay before allowing to click "OK". Many applications do this already for sensitive actions. For example Firefox for all the open/save dialogs, plugin installation etc.
Also a solution would be to get rid of confirmations for possibly dangerous actions and simply deny them by default...

Interestingly there is also "Activate focus stealing prevention" option in the "Window Manager Tweaks" pane's Focus tab. I haven't tested it, and could find any description how it is expected to work. I keep it disabled, FWIW.

I've tried this, but it looks to have no effect at all, at least I haven't noticed any. In theory it should be something like "don't give focus to newly created windows, if user is active in the current one".

[marmarek]

It seems one can get rather effective focus stealing prevention in Xfce by unticking "Automatically give focus to newly created windows" in the "WIndow Manager" pane, Focus tab.

Yes, it may solve one of the problem: focus stealing by just opening new window (like launching something requiring user confirmation) and having focus there.
But it does not solve the other problems:

• focus stealing by closing the current window.
• focus stealing by launching new window just under mouse cursor (before anticipated click) - which includes also convincing the user to click in particular place (for example using a simple game...).

In the first case, if someone want to fool user into confirming some action, the attacker needs to predict when user will press enter, then:

1. Launch the action (which will result in confirmation dialog)
2. Close the current window

You can try this by opening terminal, then launching gnome-terminal & exit. The new terminal window will receive focus. Without this option enabled, exit is not needed.

So, in practice this option make the attack only slightly harder, but IMHO makes normal usage much more annoying. Like if I open new window (like "file->open" dialog via Ctrl-O in some application), I need to do additional action (switch focus - one click, or Alt-tab) to do the task. Every time.

I think the ultimate solution for focus stealing in qrexec confirmations is to force some delay before allowing to click "OK". Many applications do this already for sensitive actions. For example Firefox for all the open/save dialogs, plugin installation etc.
Also a solution would be to get rid of confirmations for possibly dangerous actions and simply deny them by default...

Interestingly there is also "Activate focus stealing prevention" option in the "Window Manager Tweaks" pane's Focus tab. I haven't tested it, and could find any description how it is expected to work. I keep it disabled, FWIW.

I've tried this, but it looks to have no effect at all, at least I haven't noticed any. In theory it should be something like "don't give focus to newly created windows, if user is active in the current one".