"Authentication is required to create a color managed device" dialog when launching GNOME 3 or Unity 7.4 using TurboVNC

[dcommander]

When launching GNOME 3 (including Classic) in TurboVNC or resizing the remote desktop under GNOME 3, a dialog pops up ("Authentication is required to create a color managed device"), and it cannot be dismissed without authenticating using the root password. This seems to be a problem endemic to all X proxies running on recent Linux distros that use GNOME 3 (yet another reason to use MATE instead, at least with TurboVNC.)

Refer to:
https://bugzilla.redhat.com/show_bug.cgi?id=1149893
for further information, as well as a workaround.

Filing this issue to track it.

I've personally verified that the issue exists with TurboVNC 2.1 beta and TigerVNC 1.6 (both the "el5" flavor, which is based on the same X.org 7.7/xorg-xserver 1.12 code as TurboVNC, and the "el6" flavor, which is based on xorg-xserver 1.15.) Verified that the workaround listed at the above link solves the problem, but since that workaround requires specifying a group to which to grant colord permissions, it isn't exactly a generic solution.

This issue is known to exist in current versions of RHEL 7, SLES 12, Fedora 22, and Fedora 24 as of this writing. On Fedora 24, an additional dialog pops up ("Authentication is required to access to PC/SC daemon.") Refer to #52 for the workaround to that issue.

[dcommander]

Verified that a similar issue also exists under Ubuntu 16.04 with Unity 7.4. The workaround is identical, except that you add

polkit.addRule(function(action, subject) {
   if ((action.id == "org.freedesktop.color-manager.create-device" ||
        action.id == "org.freedesktop.color-manager.create-profile" ||
        action.id == "org.freedesktop.color-manager.delete-device" ||
        action.id == "org.freedesktop.color-manager.delete-profile" ||
        action.id == "org.freedesktop.color-manager.modify-device" ||
        action.id == "org.freedesktop.color-manager.modify-profile") &&
       subject.isInGroup("{group}")) {
      return polkit.Result.YES;
   }
});

to /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf instead of /etc/polkit-1/rules.d/02-allow-colord.rules. (NOTE: I personally use vglusers for {group}.)

[jcmunioz]

Thank you @dcommander I was able to fix this problem after struggling for months! Just one note, the extension of the file has to be .rules, not .conf, at least on my system (Fedora 26).
Thank you again!

[shibumi]

A little side note: That workaround does not work for LDAP users because of a problem with group policies and PAM: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1281700

[dcommander]

Really wish the various O/S and window manager developers would do a better job of supporting remote desktop solutions, in general. It boggles my mind that Red Hat and Ubuntu are allegedly providing enterprise support on an O/S with a default WM configuration that simply doesn't work with the remote desktop solution they also allegedly support. You guys would do well to lodge a complaint with your O/S vendor of choice regarding this, because it's not the only issue that occurs when trying to run these newer WM's in a VNC environment:

https://github.com/TurboVNC/turbovnc/issues?q=is%3Aissue+is%3Aclosed+label%3A%22GNOME+3%22

https://github.com/TurboVNC/turbovnc/issues?q=unity+label%3A%22Unity+7.4%22

[dcommander]

Verified that the same issue exists with GNOME 3 under Ubuntu 18.04. Use the workaround described in #47 (comment).

[shibumi]

Btw this policy kit file fixes the color profile issues for LDAP users as well:
/etc/polkit-1/localauthority/50-local.d/color.pkla

[Allow colord for all users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Note: the file MUST have the ending .pkla. Otherwise it will not work

[jramos-br]

Here (Desktop LTS 18.04.1) it works only with following configuration in /etc/polkit-1/localauthority/50-local.d/color.pkla. In fact I named it 45-allow.colord.pkla but the name can be anyone, I think.

[Allow Colord all Users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile
ResultAny=no
ResultInactive=no
ResultActive=yes

With yes in ResultAny and ResultInactive, after login the window of RDP client closes. I'm using Windows 10 as client.

I found that info in here. I'm not using TurboVNC. I'm using standard Windows RDP Client. I've posted because the info could be useful.

[dcommander]

Ah, OK. I see what the issue is. As described in http://c-nergy.be/blog/?p=12043, the procedure in #47 (comment) (creating /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf) gets rid of the dialog but causes PolKit to crash. The procedure described in #47 (comment) (creating /etc/polkit-1/localauthority/50-local.d/45-allow.colord.pkla) gets rid of the dialog with no crash. Verified on Ubuntu 16.04 and 18.04.

[dcommander]

Verified that either procedure works properly with RHEL 7 or Fedora.

[dcommander]

@shibumi can you verify that it also works for you with ResultAny=no and ResultInactive=no? It seems that we're converging upon a single solution that works on all affected platforms, in which case it should be possible to include it in the TurboVNC distribution (perhaps to be optionally activated using a configuration script similar to vglserver_config.)

[shibumi]

@dcommander haven't tested it. But I guess setting ResultAny=no will affect LDAP users right? I use this in conjunction with LDAP users. Sadly I can't try it out, because we have moved our production system at work back to x2go instead of a combination of xrdp and VNC.

[dcommander]

I honestly have no idea how that option interacts with LDAP. The description is not very enlightening:
https://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html

[tkansgar]

Hi all,

I just want confirm here, that jramos-br's solution under #47 (comment) works fine (for me) under Ubuntu 18.04 with Gnome 3.

Best regards
tkansgar

[dogweather]

The #47 comment does not work for me with Fedora 29.

[dcommander]

Works fine for me, but in Fedora, there is an additional dialog that you have to squelch:
#52
and I notice that, specifically, in FC29, there is a new dialog: "Authentication is required to refresh the system repositories." I'm not sure how to squelch that one, but I'm imagining that the process would be similar to the others.

Folks, I cannot emphasize this enough: these are hackish workarounds necessitated by the fact that GNOME 3 simply doesn't provide proper support for running in a user-level X server such as Xvnc. I have done everything I can do to support it, but there are limits to what I can do. I strongly recommend using MATE instead, or any other non-compositing window manager. GNOME 3 has performance issues in a remote display environment as well. The best I can say about it vis-a-vis TurboVNC is: "It works, but I don't recommend it."

If someone comes up with a solution to the new dialog, feel free to post it here. Since these issues also exist with TigerVNC, the flavor of VNC that ships with Fedora, my opinion is that it should be incumbent upon the Fedora/Red Hat developers to fix them, not us.

[nacho]

@dcommander about the colord authentication dialog. This should not happen as long as you name the Output device with a VNC- prefix. i.e see https://gitlab.gnome.org/GNOME/gnome-settings-daemon/blob/master/plugins/color/gsd-color-state.c#L1032

[dcommander]

@nacho Thanks for the tip. I modified our server code so that the X RANDR output devices are named "VNC-*". Problems still persist on some platforms, but the situation is at least improved. The color management dialog no longer pops up on RHEL 8, Ubuntu 18, or Fedora.

(Where possible, all platforms were updated to the latest patches available as of today.)

O/S	gnome-settings-daemon version	observations
Fedora 29	3.30.2	"Authentication is required to access the PC/SC daemon" dialog still pops up unless the workaround from #52 is used; "Authentication is required to refresh the system repositories" dialog still pops up
Fedora 30	3.32.1	"Authentication is required to access the PC/SC daemon" dialog still pops up unless the workaround from #52 is used; "Authentication is required to refresh the system repositories" dialog still pops up
RHEL/CentOS 7.6	3.28.1	"Authentication is required to create a color managed device" dialog still pops up unless aforementioned workaround is used
RHEL/CentOS 8	3.28.1	"Authentication is required to refresh the system repositories" dialog still pops up
Ubuntu 18.04 LTS	3.28.1	no dialogs pop up

[dcommander]

The workaround described here:
https://c-nergy.be/blog/?p=14051
effectively disables the "system repositories" dialog on RHEL/CentOS 8 and Fedora.

[dcommander]

This should now be fixed in dev/3.0 evolving. The RPM and DEB packages now include
/etc/polkit-1/localauthority/50-local.d/45-turbovnc-gnome3.pkla
with the following contents:

[Eliminate GNOME 3 dialogs in TurboVNC]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile;org.debian.pcsc-lite.access_pcsc;org.freedesktop.packagekit.system-sources-refresh
ResultAny=no
ResultInactive=no
ResultActive=yes

That fixes this issue on all of the platforms I tested, but please let me know if I missed something.

[iskunk]

I've encountered this issue myself with xrdp, and have made use of the workaround in the 2018-08-12 comment above. I'd like to add a few remarks.

First, the workaround appears to be overriding a PolicyKit policy file, which on my (Ubuntu) system is located at /usr/share/polkit-1/actions/org.freedesktop.color.policy. This is an XML file that is basically a verbose form of the .pkla file already discussed. The most interesting parts of it are the default permissions given for each of the six actions of interest:

    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>

The first proposed .pkla file had all three permissions set to yes, but this is actually a needless (and potentially risky) loosening of the security restrictions. Setting allow_any/ResultAny to no is the correct approach, as this tightens the restriction on the "any" class from "allow with admin credentials" to "unconditional deny." The other two permissions need not even be mentioned in the .pkla file to yield an effective workaround, and it is perhaps best to remove them. Here is what I am using:

# /etc/polkit-1/localauthority/50-local.d/colord-zap-auth.pkla

[Zap colord authentication dialogs for remote graphical users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile
ResultAny=no

(Incidentally, for those who need it, the meaning of the three permissions is documented in the pklocalauthority(8) man page. Remote sessions fall into the "any" bucket.)

Second, I would point out that .pkla files are just GLib GKeyFile files. Comment lines marked by # as well as blank lines are permitted. I would suggest including some descriptive text/links in the distributed .pkla file, to better explain its purpose to anyone reviewing the security of the system.

Third, to @nacho: It is good that there is a way to get around this issue by way of the device naming convention. Would it be feasible to add similar support for xrdp?

$ xrandr --listactivemonitors
Monitors: 1
 0: +rdp0 1600/423x1200/317+0+0  rdp0

It may be worthwhile to discuss with their upstream a convention for this (I would have expected RDP-0 or RDP-1), and there are certainly other protocols in play (e.g. NX, X2Go) that can be addressed as well.

[dcommander]

@iskunk Thanks for the explanation. I've pushed a commit (44c5a1a) to the dev/evolving 3.0 branch that generates a PKLA file when creating an RPM or DEB package using the TurboVNC build system. I will modify the generated file according to your suggestions.

[dcommander]

After thorough testing, and since I now have a better understanding of the security ramifications, the PKLA file has been pushed to master (the upcoming 2.2.5 release) as well.