gnome-extensions allows to enable/disable extensions even if they have been locked down via dconf (Shell version 42 and 43 at least)
Affected version
This bug is reproducible with GNOME shell 43 (Debian Sid, Xorg) and GNOME shell 42 (Ubuntu Jammy, Wayland). I haven't tested with other environments yet.
Bug summary
We have installed a set of extensions system-wide (in /usr/share/gnome-shell/extensions/
) and enabled them and locked them down as shown here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/extensions-mandatory
So, basically, we have set /org/gnome/shell/enabled-extensions
via system-wide dconf and added the path to a dconf-locks file as well. The graphical interface (gnome-shell-extension-prefs
) then shows all extensions greyed-out as one would expect. But the user can still run:
gnome-extensions enable/disable <UUID>
and the chosen extension will be enabled/disabled and e.g. gnome-shell-extension-prefs
will confirm that. We also found that if a user had disabled one of the extensions before, our dconf files would not force-enable that extension. Instead, the user's previous decision would prevail.
Steps to reproduce
First scenario (only show that users can enable/disable extensions despite the dconf lock):
- install an extension into
/usr/share/gnome-shell/extensions/
- make sure /etc/dconf/profile/user exists (https://help.gnome.org/admin/system-admin-guide/stable/dconf-custom-defaults.html.en)
- create /etc/dconf/db/local.d/00-extensions and set
[org/gnome/shell]
->enabled-extensions
- create /etc/dconf/db/local.d/locks/00-extensions and add
/org/gnome/shell/enabled-extensions
- add
development-tools
as shown in the red-hat manual accordingly if you want - run
dconf update
and restart GNOME shell - create a new user
- log in as this new user
- the extension GUI is showing the chosen extension as enabled and grays out the option to disable it
- run
gnome-extensions disable <UUID>
for that extension and that extension will be shown as disabled afterwards and will have been turned off
To demonstrate the second issue:
- Turn off that extension as the user via
gnome-extensions disable <UUID>
- Delete the created dconf files and remove/uninstall the extension as well
- run
dconf update
and restart GNOME shell - check that the GUI and
gnome-extensions list
doesn't show this extension anymore - now repeat steps from first scenario without creating a new user (we use the user created above)
- the extension will not be shown as enabled (it seems the decision to disable this extension has been remembered, and it prevails over the dconf settings)
Our scenario: We install extensions via ansible into new and existing systems. There should be a bunch of mandatory extensions and the user should not be able to change that (neither disable them nor enable others). This should work with both, existing and new users. Previous settings should not prevail.
What happened
Even with the dconf settings locking the enabled extensions, it seems that the user can still enable/disable extensions via gnome-extensions
command. Because this AFAIK uses dbus, I guess that the dbus methods don't care/know about the lock. Also, it seems that previous settings, having an extension disabled as user, prevail over the locked dconf setting.
What did you expect to happen
The locked dconf setting prevails, and users cannot enable/disable extensions after locking the setting via dconf.
Relevant logs, screenshots, screencasts etc.
If necessary, I can provide this.