Bug 1329803

Summary:	gnome-shell to set LockedHint property from logind
Product:	Red Hat Enterprise Linux 7	Reporter:	Victor Toso <victortoso>
Component:	gnome-shell	Assignee:	Florian Müllner <fmuellner>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	lmiksik, mboisver, rstrode, tpelka
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-04 01:44:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1335499
Bug Blocks:	1323623

Description Victor Toso 2016-04-23 11:06:33 UTC

Description of problem:
Logind is not used to the lock the session but it is always used to unlock it by gdm. This makes it hard to reliably track if session is locked or not.


Steps to Reproduce:
You can verify it by monitoring the Session from login1 and Locking you session.

gdbus monitor --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1/session/_31

Actual results:
You can see that the Unlock signal was emitted but Lock was not. It is also possible to see that IdleHint property changed correctly but that isn't reliable enough IMHO (It is broken in my F23, for instance)

Expected results:
Lock signal should be emitted.


Additional info:
Bug was filled upstream as well [0] and this is interesting for spice-vdagent in order to disable features like drag-and-drop when system is locked [1]

[0] https://bugzilla.gnome.org/show_bug.cgi?id=764773
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1323623

Comment 2 Ray Strode [halfline] 2016-05-09 15:28:26 UTC

So we can fix gnome-shell to lock itself via logind but:

1) doing it introduces a race where logind will emit Locked before it's actually Locked (unless gnome-shell calls logind's Lock method after it's already locked and then ignores the ensuring locked signal itself)

2) I don't think any other desktop environment does locking that way at the moment.  The cross desktop api for screen locking is the org.freedesktop.ScreenSaver interface (which is a bit of a misnomer) so I'd recommend vdagent use that.

Comment 3 Ray Strode [halfline] 2016-05-09 18:27:04 UTC

So actually the cross desktop api for screen locking won't work.  Our implementation is currently this:

        } else if (g_strcmp0 (method_name, "GetActive") == 0) {•
                goto unimplemented;•
        }

So you'd need to use org.gnome.ScreenSaver.GetActive instead for RHEL.

Comment 4 Victor Toso 2016-05-12 10:38:42 UTC

Another way to have this is by using logind's new property LockedHint.
gnome-shell can set this property and applications can query it to track if session is Locked or not.

Proposal patch on upstream bugzilla.

Comment 5 Victor Toso 2016-05-16 08:53:59 UTC

Changing the summary based on comment #4

Patch for this is upstream:
https://git.gnome.org/browse/gnome-shell/commit/?id=ddea54a5398c123a4711243e55811c8ba26f8b85

Comment 7 Victor Toso 2016-08-11 13:45:57 UTC

Just for future reference, build with this patch is:
3.14.4-45

Comment 10 errata-xmlrpc 2016-11-04 01:44:21 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2258.html