xubuntu does not disable gtk overlay scrollbars (i.e. use solid scrollbars)

[Jonathan Joseph Chiarella]

xubuntu does not disable gtk overlay scrollbars (i.e. use solid scrollbars)

On this page http://tracker.xubuntu.org/ in the source code, Sean Davis is assigned to disable gtk3.16 overlay scrollbars in xubuntu-default-settings (i.e. use solid scrollbars) and https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-development shows also that the work is done.

I am running xubuntu 15.10 beta 2 and this is not the case.

Opening up ubuntu-modified programmes shows solid scrollbars (like the non-csd-ized, non-header-bar-ized evince), but synaptic shows overlay scrollbars.

I find it very annoying. There is no visual clue of a scrollbar until I move my mouse over the window, and unlike Android or iOS scrollbars, the width changes and the transparency changes depending on how close my mouse is.

Very hard to use.

Please fix.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: xubuntu-default-settings 15.10.3
ProcVersionSignature: Ubuntu 4.2.0-11.13-generic 4.2.1
Uname: Linux 4.2.0-11-generic x86_64
ApportVersion: 2.18.1-0ubuntu1
Architecture: amd64
CasperVersion: 1.365
CurrentDesktop: XFCE
Date: Mon Sep 28 04:43:49 2015
LiveMediaBuild: Xubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150924)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: xubuntu-default-settings
UpgradeStatus: No upgrade log present (probably fresh install)

[Sean Davis (bluesabre)]

This is likely because Synaptic is launched as a root user. If running synaptic from the commandline without sudo, the overlay scrollbars are not used.

Most likely, pkxec does not pass the DESKTOP_SESSION variable when launching an application, so we don't gain the benefits from /etc/X11/Xsession.d/56xubuntu-session

[Jonathan Joseph Chiarella (jonathan-chiarella-deactivatedaccount)]

Thank you for the quick response. I didn't even think bout how root privileges entered into it. I remember from trying out kde in transition (4->5) that apps run as root from get-go had messed up display settings (icons were mix-and-match, etc).

I'm not totally against the overlay scrollbars and thy may be for the best in the long run, especially if it's going to remain default in gtk3. (I think traditional dialogs with ssd are default as well if I''m not mistaken. The defaults aren't crazy)

Manjaro does a good job of it. They make sure that the overlay scrollbars stay at a consistent width and mesh well with gtk2. The only problem is there, and anywhere else using xfce 4.12, is that instead of all apps showing a gtk2 theme or a gtk3 one, they generally show gtk2 or they show gtk3 if natively gtk3. The result is that overlay bars are on some apps and not others. It's not just inconsistent, but also makes me make mistakes. If only some apps have the overlay, I won't bother to check to check if the text in the window continues left or right. If they're all like that, then it's alright, but until xfce converts to gtk3, I think the inconsistency will continue, especially if firefox and libreoffice and chromium don't play nicely (being they're gtk2 ontop of other toolkits).

In any case, is this disconnect from gtk3 apps in xfce and root-enabled gtk3 apps in xfce something we can avoid? Is it possible to tweak the ubuntu settings for pkexec? Or does this have to be fixed upstream?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Philip Müller (philm)]

Created attachment 124768
Patch which adds those listed variables

Even though when pkexec is not designed to run X11 apps it shouldn't remove environment variables for GUI apps. They are needed for proper look&feel integration.

GUI applications need the following environment variables forwarded:

KDE_FULL_SESSION
KDE_SESSION_VERSION
DESKTOP_SESSION
GNOME_DESKTOP_SESSION_ID
XDG_CURRENT_DESKTOP
QT_STYLE_OVERRIDE
QT_XCB_FORCE_SOFTWARE_OPENGL
QT_QPA_PLATFORMTHEME

There are some more that may make sense to forward, such as KDE_IS_PRELINKED, QT_PLUGIN_PATH, XDG_DATA_DIRS etc., but some of those may be considered security issues. The ones in my list above are perfectly safe though.

[Philip Müller (philm)]

remove 'DESKTOP_ENVIRONMENT' as it may contain '/' which forces pkexec to bail out

[manjaro@manjaro ~]$ pkexec calamares
The value for environment variable DESKTOP_SESSION contains suscipious content

This incident has been reported.
[manjaro@manjaro ~]$ echo $DESKTOP_SESSION
/usr/share/xsessions/plasma

[Philip Müller (philm)]

Created attachment 124770
Patch which adds those listed variables (v2)

[Miloslav Trmac (mitr-redhat)]

From an one-minute look:

* KDE_SESSION_VERSION:
https://userbase.kde.org/KDE_System_Administration/Environment_Variables:
 > This allows one to know which kde?-config to run: kde${KDE_SESSION_VERSION}-onfig.

explicitly recommending to use the variable in an unsafe way. (and /usr/bin/xdg-* programs really do that!)

* GNOME_DESKTOP_SESSION_ID: Reportedly deprecated since 2009 ( https://bugzilla.redhat.com/show_bug.cgi?id=529287 )

* QT_STYLE_OVERRIDE: Apparently this can dynamically load plugins? Why is it safe? It might be, but the path lookup stack is too deep for a quick inspection or to be confident that it doesn’t pull from the current directory or so.

* QT_QPA_PLATFORMTHEME: Similar, and there is even an explicit -platformpluginpath

I’m sorry but this does not look all that obviously safe and I probably won’t have time to do a week-long research on this. Colin, if you know more, feel free to merge.

[Rex Dieter (rdieter)]

fwiw, I opened bug #96730 against xdg-utils to track this insecure use of KDE_SESSION_VERSION environment variable.

[Miloslav Trmac (mitr-redhat)]

(In reply to Rex Dieter from comment #4)
> fwiw, I opened bug #96730 against xdg-utils to track this insecure use of
> KDE_SESSION_VERSION environment variable.

Well, the code is using the variable _exactly as documented_; it is perfectly secure to use it within a session. It is just not secure to transfer the value across trust domains (like pkexec would).

[Miloslav Trmac (mitr-redhat)]

(In reply to Miloslav Trmac from comment #3)
> From an one-minute look:
(to be fair, turned out to be 50 minutes actually :) )

[Miloslav Trmac (mitr-redhat)]

I guess, how to move this forward: Basically there should be, for every instance, a reasoned argument why passing that variable is safe, ideally verifiable by third parties (you can assume that I know about nothing about KDE, and we can’t assume anything about future maintainers).

That reasoned argument may have various forms, the only requirement is that it exists and that it is credible. For example:
- Longstanding practice of passing that value around through privilege escalation points (like the `LC_` variables)
- Explicit documentation by (the only plausible) user that the variable is safe to pass from untrusted sources (I can’t think of an example).
- Manual verification of all relevant users and some argument that they won’t change.
- Limiting the values to a strict range of clearly safe values.

In particular that last one could be attractive because it makes the research very localized and trivial to verify. For example, limiting KDE_SESSION_VERSION to only three values "", "3" and "4" would be, I guess, obviously safe, and sufficient?

Similarly COLUMNS/LINES limited to integers in range 10-200, with no leading zeroes or any funky formatting, could be fine.

The PLATFORMTHEME/STYLE_OVERRIDE are worse, in that just limiting them to known theme names is alone not enough to demonstrate that plugins can’t be loaded from untrusted directories. Perhaps there is a simple way to ensure that?

[Jonathan Joseph Chiarella (jonathan-chiarella-deactivatedaccount)]

Problem is still active as of 16.10. Otherwise, a very happy camper.

There are niggling Ubuntu-isms like that Unity Music Menu and Messaging Menu, but they are easily replaced/disabled/uninstalled. Still unable to figure how to edit configuration files to fix Synaptic. Yet other root apps activated via pkexec work as expected. Is there something particular to Ubuntu or to the Debian app, Synaptic, specifically?

It's not huge, but it's a bit disorienting, especially since the rest of the desktop uses solid scrollbars. Frankly, it really only works on mobile or small screen or touch interfaces. Mouse-users need to know where to put the mouse and jiggling the cursor to make scrollbars appear before clicking on the section where the page is on the scrollbar (the off-colored block), is not much fun.

Probably the biggest complaint after not having Linux installations run popular Windows apps, is the lack of consistency. Synaptic doesn't make the library/executable distinction obvious, but I still recommend it for newbies. The command line is scary and the Ubuntu Software Center and every DE native installer (Gnome, KDE Apper, etc) are unstable and/or slow as molasses. Using a search text box in Synaptic, on the other hand, isn't far from typing in "0AD" into Google and looking for the .exe. The overlays only work with GTK3 apps anyhow. So, even if you love them, running any Gtk2 or Qt apps ruins the consistency and makes the desktop look more like a jerry rig.

Sorry for the rant. It's really more the Gnome people making things difficult for anything non-Gnome and assumes no other software will ever be installed. At least, they made Gtk3 dialogs behave with normal ssd outside Gnome and Gnome app menus have a sane fallback. Hearing "where did the scrollbar go?" is not a good thing to hear when converting people. On the plus side, Gtk 3 finally stabilized everything with 3.20 and 3.22 will be viable for some time and does Wayland. Then we can put this behind us. (I hope)

[Rstrode (rstrode)]

given last comment let's close this.

[Sean Davis (bluesabre)]

Closing as won't fix. This won't be addressed by Xubuntu.