GNOME Bugzilla – Bug 780866
launch-environment: Don't set DCONF_PROFILE for gnome-initial-setup
Last modified: 2017-04-04 11:29:22 UTC
In Endless, we have been carrying a patch for a while[1] to prevent setting the DCONF_PROFILE variable for gnome-initial-setup, as that would prevent us from overriding things (e.g. the background) via GSettings overrides, which we install at the time of building certain images. I'm now just rebasing our old GDM 3.14 on top of 3.22 and found that our patch would be much smaller and cleaner now[2], so I'm filing this ticket to see if we could get it landed upstream too, as I don't think this is an Endless-specific thing. [1] https://github.com/endlessm/gdm/commit/95332ca2 [2] https://github.com/endlessm/gdm/commit/b1dee735
Created attachment 349171 [details] [review] Patch proposal attached (backport from Daniel Drake's original patch)
Review of attachment 349171 [details] [review]: so i really have only two concerns with this: 1) a11y will get disabled 2) disabling the lockdown might have security implications ? The latter I guess isn't a huge concern. I mean gnome-initial-setup lets you create an admin user... Still I wonder why the patch is needed? i don't think GDM locks down picture-uri or whatever.
(In reply to Ray Strode [halfline] from comment #2) > Review of attachment 349171 [details] [review] [review]: > > so i really have only two concerns with this: > > 1) a11y will get disabled Can you elaborate a bit more on this? Why would it get disabled? > 2) disabling the lockdown might have security implications ? > > The latter I guess isn't a huge concern. I mean gnome-initial-setup lets > you create an admin user... > > Still I wonder why the patch is needed? i don't think GDM locks down > picture-uri or whatever. It's not my patch so perhaps Daniel or Cosimo, who originally worked on it on the Endless side, might be better to answer this question. My understanding, though, is that we want to be able to specify some things such as the background on an per-image basis, using GSettings overrides, and having the DCONF_PROFILE envvar would break that as it would override anything set via GSettings.
Argh! Unfortunately, I pushed by mistake this patch when pushing the one for bug 780862 (I'd swear I had reset --hard HEAD^ first, but seems like I did not): https://git.gnome.org/browse/gdm/commit/?id=67ef79c125c34b66072ae00927b2c89f2c98f196 I think I should revert it now while there's not an agreement on whether it can be landed, but before creating an even bigger mess, I'll wait for you (plural) to reply to my previous comment, if that's ok. Sorry in any case
(In reply to Mario Sánchez Prada from comment #3) > Can you elaborate a bit more on this? Why would it get disabled? This is currently shipped in the gdm profile [org/gnome/desktop/a11y/keyboard] enable=true [org/gnome/desktop/interface] toolkit-accessibility=true > It's not my patch so perhaps Daniel or Cosimo, who originally worked on it > on the Endless side, might be better to answer this question. My > understanding, though, is that we want to be able to specify some things > such as the background on an per-image basis, using GSettings overrides, and > having the DCONF_PROFILE envvar would break that as it would override > anything set via GSettings. AFAIK, gsettings override files should work fine... it's not like we specify a background in the GDM.
(In reply to Ray Strode [halfline] from comment #5) > (In reply to Mario Sánchez Prada from comment #3) > > Can you elaborate a bit more on this? Why would it get disabled? > > This is currently shipped in the gdm profile > > [org/gnome/desktop/a11y/keyboard] > enable=true > > [org/gnome/desktop/interface] > toolkit-accessibility=true Ah, I see... that makes sense now, thanks for clarifying. I thought a11y was enabled by default, though, and that GDM will pick the defaults if no DCONF_PROFILE was found, unless overriden (e.g. via GSettings), but maybe I was guessing too much? > > It's not my patch so perhaps Daniel or Cosimo, who originally worked on it > > on the Endless side, might be better to answer this question. My > > understanding, though, is that we want to be able to specify some things > > such as the background on an per-image basis, using GSettings overrides, and > > having the DCONF_PROFILE envvar would break that as it would override > > anything set via GSettings. > > AFAIK, gsettings override files should work fine... it's not like we specify > a background in the GDM. It doesn't, I think, but Cosimo or Daniel will probably be able to clarify this much better.
gsettings override files do work fine, but I guess this was originally implemented by Cosimo as a dconf change because you can do that in /etc which is outside of the ostree (in Endless this is a per-image-flavour modification that we do outside of the generic ostree). However $XDG_DATA_DIRS does include /usr/local/share and /usr/local is a symlink to /var/local so I guess we could potentially put a glib override in /var instead.
FWIW, I reverted the patch I landed by mistake in the first place, not to forget: https://git.gnome.org/browse/gdm/commit/?id=49dacac7728061636a04e3757670c874965d35be
i guess you could change /etc/dconf/profile/gdm to have a system-db: line too?
Ray, gsettings schema overrides indeed work fine without this patch. What the patch will fix is the case where the default dconf user profile includes different defaults. In Endless, /etc/dconf/profile/user looks like this: user-db:user file-db:/var/eos-image-defaults/settings DCONF_PROFILE being set will make dconf ignore the default profiles altogether, which is what gdm wants since it ships its own. But I don't think that should be propagated to the initial-setup session.
Also, please see my question with regard to a11y being disabled without passing DCONF_PROFILE=gdm, my understanding is that a11y is enabled by default, so I don't see why having a profile specified would be needed (maybe it is for the a11y keyboard?).
(In reply to Cosimo Cecchi from comment #10) > Ray, gsettings schema overrides indeed work fine without this patch. > What the patch will fix is the case where the default dconf user profile > includes different defaults. In Endless, /etc/dconf/profile/user looks like > this: > > user-db:user > file-db:/var/eos-image-defaults/settings So why don't you make /etc/dconf/profile/gdm look like this: user-db:user file-db:/usr/share/gdm/greeter-dconf-defaults file-db:/var/eos-image-defaults/settings ? > But I don't > think that should be propagated to the initial-setup session. Well there are certain things that initial-setup should have too (like the a11y stuff). We could have a separate initial-setup profile I guess... maybe overkill though?
(In reply to Mario Sánchez Prada from comment #11) > Also, please see my question with regard to a11y being disabled without > passing DCONF_PROFILE=gdm, my understanding is that a11y is enabled by > default, so I don't see why having a profile specified would be needed > (maybe it is for the a11y keyboard?). Nope it's not. Just run gsettings get org.gnome.desktop.a11y.keyboard enable gsettings get org.gnome.desktop.interface toolkit-accessibility in your session to see. Also note you don't see a vitruvian man in the upper right corner unless you enable an a11y feature in control-center...
(In reply to Ray Strode [halfline] from comment #13) > (In reply to Mario Sánchez Prada from comment #11) > > Also, please see my question with regard to a11y being disabled without > > passing DCONF_PROFILE=gdm, my understanding is that a11y is enabled by > > default, so I don't see why having a profile specified would be needed > > (maybe it is for the a11y keyboard?). > Nope it's not. Just run > > gsettings get org.gnome.desktop.a11y.keyboard enable > gsettings get org.gnome.desktop.interface toolkit-accessibility > > in your session to see. Also note you don't see a vitruvian man in the > upper right corner unless you enable an a11y feature in control-center... Interesting... my understanding is that GNOME enabled accessibility by default since 3.6, but I just tried on my Fedora VM and it's indeed... disabled. I'm adding Alejandro to CC to see if he can drop some light on that. I wonder when this changed along the way, this was supposed to fix a big problem for a11y users, but perhaps it was not mature enough?.. I'm clearly outdated now :(.
(In reply to Ray Strode [halfline] from comment #12) > So why don't you make /etc/dconf/profile/gdm look like this: > > user-db:user > file-db:/usr/share/gdm/greeter-dconf-defaults > file-db:/var/eos-image-defaults/settings > > ? Yeah, that would also solve the issue. I did not go that way because: - it can be a bit cumbersome to ensure that file is updated for all existing users (people may have modified it since it's in /etc) - if one day we changed the location of our overrides, we'd have one more file to update - it didn't feel right to me that the gdm session was also used for initial-setup, since the same policies should not necessarily be applied to both > > But I don't > > think that should be propagated to the initial-setup session. > Well there are certain things that initial-setup should have too (like the > a11y stuff). > > We could have a separate initial-setup profile I guess... maybe overkill > though? I see, I wasn't aware that the initial-setup session was relying on those from gdm. On the other hand it looks to me that g-i-s "session mode" implementation for the shell forces the vitruvian man icon on the panel regardless of the settings [1], and those gsettings would get toggled appropriately by g-s-d already when some toggles in there are flipped, no? [1] https://git.gnome.org/browse/gnome-initial-setup/tree/data/initial-setup.json -- a11yGreeter is an implementation of the a11y status menu that is always visible.
(In reply to Mario Sánchez Prada from comment #14) > (In reply to Ray Strode [halfline] from comment #13) > > (In reply to Mario Sánchez Prada from comment #11) > > > Also, please see my question with regard to a11y being disabled without > > > passing DCONF_PROFILE=gdm, my understanding is that a11y is enabled by > > > default, so I don't see why having a profile specified would be needed > > > (maybe it is for the a11y keyboard?). > > Nope it's not. Just run > > > > gsettings get org.gnome.desktop.a11y.keyboard enable > > gsettings get org.gnome.desktop.interface toolkit-accessibility > > > > in your session to see. Also note you don't see a vitruvian man in the > > upper right corner unless you enable an a11y feature in control-center... > > Interesting... my understanding is that GNOME enabled accessibility by > default since 3.6, It is enabled by default on gtk 3.x and gnome-shell. But ... > but I just tried on my Fedora VM and it's indeed... > disabled. I'm adding Alejandro to CC to see if he can drop some light on > that. ... it is not for gtk2 apps and other legacy applications/toolkits. The rationale then was that we were doing the switch to enabled by default because there were several improvements on gtk3 accessibility support, specifically Benjamin work on the treeview. But those changes were not backported (and will not be backported) to gtk2. FWIW, one of those gtk2 apps is firefox, that although it is not official part of GNOME, has a large user base among GNOME users. > I wonder when this changed along the way, It didn't change, afaik. > this was supposed to fix a big > problem for a11y users, but perhaps it was not mature enough?.. I'm clearly > outdated now :(. What I explained was as it is since we enabled a11y by default on 3.6. Perhaps we should have been more clear about not affecting all the apps. But in general "default GNOME" is gtk3.
We're not talking about gtk2 or legacy apps here, but about GDM running in "initial-setup" mode, which basically impacts the execution of gnome-initial-setup, which is a GTK3 (3.22) application, not an old one. I guess my question is why this: gsettings get org.gnome.desktop.a11y.keyboard enable gsettings get org.gnome.desktop.interface toolkit-accessibility ...returns false/disabled by default if, in theory, a11y should be enabled by default since 3.6. That's the bit I don't understand, and the one that I believe is important to the discussion at hand.
(In reply to Mario Sánchez Prada from comment #17) > We're not talking about gtk2 or legacy apps here, but about GDM running in > "initial-setup" mode, which basically impacts the execution of > gnome-initial-setup, which is a GTK3 (3.22) application, not an old one. > > I guess my question is why this: > gsettings get org.gnome.desktop.a11y.keyboard enable > gsettings get org.gnome.desktop.interface toolkit-accessibility > > ...returns false/disabled by default if, in theory, a11y should be enabled > by default since 3.6. FWIW, being nitpicky, it is not "enabled by default" but "always on". Im saying that because in the practice, it means that gtk3 and gnome-shell doesn't check for toolkit-accessibility. For example on gnome-shell: https://git.gnome.org/browse/gnome-shell/tree/src/main.c#n266 There, a11y is activated without checking. > That's the bit I don't understand, and the one that I > believe is important to the discussion at hand. toolkit-accessibility is a legacy setting. It is only used by gtk2 apps and other apps. And that is the reason it disabled by default. Or in other words, yes toolkit-accessibility returns false. But that doesn't affect gtk3 or gnome-shell because they ignore that setting
Ahh, so does that mean that gnome-initial-setup would have a11y on regardless of those two settings?
(In reply to Mario Sánchez Prada from comment #19) > Ahh, so does that mean that gnome-initial-setup would have a11y on > regardless of those two settings? If it is a gtk3 app (something I assume it is), it should. But it would be good to check it, just in case (/me on paranoid mode)
what about accessx hotkeys? anyway, thus discussion has convinced me of two things 1) pushing patch is ik 2) gdm doesnt need to set those two keys for the greeter session either. mario do you mind pushing a patch to remove them from 00-upstream-settings too?
(In reply to Ray Strode [halfline] from comment #21) > what about accessx hotkeys? I think Alejandro is probably better qualified to answer this. > anyway, thus discussion has convinced me of two > things > > 1) pushing patch is ik Ok, I'll re-push it then. > 2) gdm doesnt need to set those two keys for the greeter session either. > mario do you mind pushing a patch to remove them from 00-upstream-settings > too? Sure, no problem. Thanks!
Pushed: https://git.gnome.org/browse/gdm/commit/?id=edc18151752d4f8fec4b9052aa5cf455ff3fb1a6 https://git.gnome.org/browse/gdm/commit/?id=3c78aa318bffeeccd8d0899fb005ec5782e79119