1414898 – after disabling screen lock in gnome, Super-L shortcut still works to lock screen

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1414898 - after disabling screen lock in gnome, Super-L shortcut still works to lock screen

Summary: after disabling screen lock in gnome, Super-L shortcut still works to lock sc...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	gnome-shell
Sub Component:
Version:	7.3
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Florian Müllner
QA Contact:	Desktop QE
Docs Contact:	Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2017-01-19 16:59 UTC by jas
Modified:	2023-07-25 21:01 UTC (History)
CC List:	5 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-08-01 22:44:12 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
GNOME Bugzilla	780212	0	Normal	RESOLVED	Do not lock the screen when disabled by lockdown settings	2021-02-16 14:54:39 UTC
Red Hat Product Errata	RHBA-2017:2098	0	normal	SHIPPED_LIVE	gnome-shell-extensions, gnome-shell, mutter bug fix and enhancement update	2017-08-01 19:36:42 UTC

Description jas 2017-01-19 16:59:47 UTC

Description of problem:

Disable screen lock in GNOME with this dconf entry:

[org/gnome/desktop/lockdown]
disable-lock-screen=true

However, Super-L still locks screen!

If the function is "disabled", then it should be entirely disabled.

I'm in an academic environment.  I don't want students to be able to lock screens, but I do want faculty, etc. to be able to do it.  Since GNOME doesn't allow this flexibility, I want to just find an external lock solution that I can script to check the users group, but to be able to use that, I need to be able to disable screen locking entirely through gnome!

Comment 2 Michael Boisvert 2017-06-06 20:56:11 UTC

I can successfully disable screen lock in gnome 3.22.

Comment 5 Michael Boisvert 2017-06-22 13:28:48 UTC

I have two 7.4 machines with snap4 on them. The menu is not honoring the lockdown settings on either. In fact, if I lock the screen with the menu I can then subsequently lock the screen with super + L after that. Something isn't right here.

Comment 6 Florian Müllner 2017-06-22 13:35:44 UTC

What is the output of

  $ gsettings get org.gnome.desktop.lockdown disable-lock-screen

Comment 7 Michael Boisvert 2017-06-22 13:58:21 UTC

(In reply to Florian Müllner from comment #6)
> What is the output of
> 
>   $ gsettings get org.gnome.desktop.lockdown disable-lock-screen

It was set to false, don't know how. If I set it to true, screenlock functionality is totally disabled. 

Problem is, if the customer is going to be using the dconf entry method, it doesn't seem reliable. 

1. Create dconf entry as per #c0
2. dconf update.
3. Super + L doesn't lock screen but menu does.
4. Lock screen with menu option, now super + L can lock screen.
5. Notice "$ gsettings get org.gnome.desktop.lockdown disable-lock-screen" is set to false. 

What do you think? If the dconf entry method is a documented way of disabling the screenlock, it should work. Also just verified my findings on a third machine.

Comment 8 Florian Müllner 2017-06-22 14:15:04 UTC

(In reply to Michael Boisvert from comment #7)
> Problem is, if the customer is going to be using the dconf entry method, it
> doesn't seem reliable. 
> 
> 1. Create dconf entry as per #c0
> 2. dconf update.
> 3. Super + L doesn't lock screen but menu does.

No, that's not supposed to work. You need to log out first, see the info box on https://help.gnome.org/admin/system-admin-guide/stable/dconf-profiles.html.en.

Comment 9 Florian Müllner 2017-06-22 14:16:36 UTC

Mmmh, actually when the profile already exists, `dconf update` is supposed to work according to https://help.gnome.org/admin/system-admin-guide/stable/dconf-keyfiles.html.en ...

Comment 10 Michael Boisvert 2017-06-22 14:36:36 UTC

Some more info. After dconf update, when the super + L screenlock is still disabled, "$ gsettings get org.gnome.desktop.lockdown disable-lock-screen" is set to false.

Comment 11 Michael Boisvert 2017-06-29 15:08:46 UTC

Florian and I went over this issue side by side on different VMs until we finally found the issue. I was trying to create a dconf entry on a different path which obviously wasn't working correctly. Once I created the dconf entry on the correct path, the screenlock was disabled via menu and Super+L.

Comment 14 errata-xmlrpc 2017-08-01 22:44:12 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://access.redhat.com/errata/RHBA-2017:2098

Comment 15 Jay Kirk 2023-07-25 21:01:05 UTC Comment hidden (spam)

This solution does not seem to be useful for all situations. Of course, it is important to ensure the security and confidentiality of the information that is stored on computers, but some students try to access other people's computers when they are locked, using various tricks and hacks. To prevent this, educators and other staff want to be able to lock their screens as they see fit rather than the default. However, GNOME does not allow this flexibility and requires a screen lock via Gnome for all users. I think this can be solved by creating an external screen lock program to check the user's group and give him the appropriate rights and settings. However, this needs to be able to completely disable the screen lock via gnome so that there are no conflicts. Unfortunately, GNOME does not allow you to do this easily and safely, so this solution requires additional effort and knowledge. One can compare this situation with the story https://writingbros.com/essay-examples/portrayal-of-disability-and-summary-of-forrest-gump/, which went through many trials. However, despite his disability, he did not give up and continued to solve problems, as shown in this essay sample. It can be said that GNOME is a handicap for users who want more flexibility and choice regarding screen locks. They must put in extra effort and creativity to find a solution to their needs.

Note You need to log in before you can comment on or make changes to this bug.