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

dcommander · 2016-08-09T23:15:29Z

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 · 2016-08-27T02:41:10Z

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}.)

Launch Unity in a fake DM environment similar to the one we use for the 2D Ubuntu window managers. This ensures that the compiz OpenGL plugin won't be disabled automatically under U14 if it encounters a fatal OpenGL error (such as failing to launch the TurboVNC Server session with -3dwm), and this fake DM environment is necessary to make Unity 7.4 under U16 work at all with TurboVNC (NOTE: there are still some issues with that, including #56 and #47.)

jcmunioz · 2017-08-12T01:29:34Z

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 · 2017-11-20T13:40:07Z

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 · 2017-11-20T15:50:35Z

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 · 2018-08-10T04:25:35Z

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

shibumi · 2018-08-10T07:51:47Z

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 · 2018-08-12T07:21:18Z

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 · 2018-08-16T19:10:07Z

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 · 2018-08-16T20:07:42Z

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

dcommander · 2018-08-16T22:01:57Z

@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 · 2018-08-16T22:44:12Z

@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 · 2018-08-16T23:43:58Z

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 · 2019-03-02T18:59:32Z

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 · 2019-07-02T16:52:52Z

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

dcommander · 2019-07-02T22:03:50Z

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 · 2019-07-23T15:06:38Z

@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 · 2019-07-23T18:26:20Z

@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

... from popping up on Fedora, RHEL 8, and Ubuntu 18+. The dialog still pops up on RHEL 7.x. Refer to #47

dcommander · 2020-02-12T04:17:50Z

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

... by using a PolicyKit Local Authority (.pkla) file, which is distributed in the RPM and DEB packages. Fixes #47 Fixes #52 Fixes #207

dcommander · 2020-03-04T08:07:02Z

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 · 2020-04-10T02:59:39Z

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 · 2020-04-10T03:21:13Z

@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.

... by using a PolicyKit Local Authority (.pkla) file, which is distributed in the RPM and DEB packages. Fixes #47 Fixes #52 Fixes #207

dcommander · 2020-04-29T20:09:26Z

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.

dcommander changed the title ~~"Authentication is required to create a color managed device" when launching GNOME 3 using TurboVNC (w/ -3dwm)~~ "Authentication is required to create a color managed device" dialog when launching GNOME 3 using TurboVNC (w/ -3dwm) Aug 9, 2016

dcommander added the SEP (somebody else's problem) label Aug 9, 2016

dcommander closed this as completed Aug 9, 2016

dcommander mentioned this issue Aug 15, 2016

TVNC 2.0.91 and gnome-terminal-3.10.2 on SLES 12 SP1 #43

Closed

dcommander added GNOME 3+ GNOME 3 Classic labels Aug 15, 2016

dcommander mentioned this issue Aug 19, 2016

"Authentication is required to access the PC/SC daemon" dialog when launching GNOME 3 using TurboVNC #52

Closed

dcommander added the workaround available label Aug 24, 2016

dcommander changed the title ~~"Authentication is required to create a color managed device" dialog when launching GNOME 3 using TurboVNC (w/ -3dwm)~~ "Authentication is required to create a color managed device" dialog when launching GNOME 3 or Unity 7.4 using TurboVNC (w/ -3dwm) Aug 27, 2016

dcommander added the Unity 7.4 label Aug 27, 2016

dcommander mentioned this issue Aug 20, 2017

Popup issue in KDE #101

Closed

dangpzanco mentioned this issue May 31, 2018

XRDP Gnome issues on 18.04 neutrinolabs/xrdp#1122

Closed

dcommander changed the title ~~"Authentication is required to create a color managed device" dialog when launching GNOME 3 or Unity 7.4 using TurboVNC (w/ -3dwm)~~ "Authentication is required to create a color managed device" dialog when launching GNOME 3 or Unity 7.4 using TurboVNC Aug 10, 2018

dcommander mentioned this issue Aug 10, 2018

TurboVNC on Ubuntu 18.04 not showing anything #133

Closed

metalefty mentioned this issue Sep 12, 2018

root rights when using the xorg driver neutrinolabs/xorgxrdp#126

Closed

dcommander added a commit that referenced this issue Jul 23, 2019

Server: Prevent GNOME 3 color management dialog

99c3274

... from popping up on Fedora, RHEL 8, and Ubuntu 18+. The dialog still pops up on RHEL 7.x. Refer to #47

metalefty mentioned this issue Jul 25, 2019

password authentication error neutrinolabs/xrdp#1380

Closed

dcommander mentioned this issue Feb 12, 2020

"Authentication is required to refresh the system repositories" dialog when launching GNOME 3 using TurboVNC #207

Closed

dcommander added a commit that referenced this issue Mar 4, 2020

Build: Prevent GNOME 3 auth dlgs in TVNC sessions

44c5a1a

... by using a PolicyKit Local Authority (.pkla) file, which is distributed in the RPM and DEB packages. Fixes #47 Fixes #52 Fixes #207

dcommander added fixed and removed workaround available SEP (somebody else's problem) labels Mar 4, 2020

dcommander added a commit that referenced this issue Apr 29, 2020

Build: Prevent GNOME 3 auth dlgs in TVNC sessions

f90561d

... by using a PolicyKit Local Authority (.pkla) file, which is distributed in the RPM and DEB packages. Fixes #47 Fixes #52 Fixes #207

dcommander removed GNOME 3+ Unity 7.4 labels Apr 29, 2020

dcommander mentioned this issue Feb 23, 2021

TurboVNC 2.2.5 with not allow password prompt. #272

Closed

iskunk mentioned this issue Mar 28, 2022

Unable to RDP to Ubuntu neutrinolabs/xrdp#2027

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

dcommander commented Aug 9, 2016 •

edited

Loading

dcommander commented Aug 27, 2016 •

edited

Loading

jcmunioz commented Aug 12, 2017

shibumi commented Nov 20, 2017

dcommander commented Nov 20, 2017

dcommander commented Aug 10, 2018

shibumi commented Aug 10, 2018

jramos-br commented Aug 12, 2018 •

edited

Loading

dcommander commented Aug 16, 2018

dcommander commented Aug 16, 2018

dcommander commented Aug 16, 2018

shibumi commented Aug 16, 2018

dcommander commented Aug 16, 2018

tkansgar commented Mar 2, 2019 •

edited

Loading

dogweather commented Jul 2, 2019

dcommander commented Jul 2, 2019

nacho commented Jul 23, 2019

dcommander commented Jul 23, 2019 •

edited

Loading

dcommander commented Feb 12, 2020

dcommander commented Mar 4, 2020

iskunk commented Apr 10, 2020

dcommander commented Apr 10, 2020

dcommander commented Apr 29, 2020

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

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

Comments

dcommander commented Aug 9, 2016 • edited Loading

dcommander commented Aug 27, 2016 • edited Loading

jcmunioz commented Aug 12, 2017

shibumi commented Nov 20, 2017

dcommander commented Nov 20, 2017

dcommander commented Aug 10, 2018

shibumi commented Aug 10, 2018

jramos-br commented Aug 12, 2018 • edited Loading

dcommander commented Aug 16, 2018

dcommander commented Aug 16, 2018

dcommander commented Aug 16, 2018

shibumi commented Aug 16, 2018

dcommander commented Aug 16, 2018

tkansgar commented Mar 2, 2019 • edited Loading

dogweather commented Jul 2, 2019

dcommander commented Jul 2, 2019

nacho commented Jul 23, 2019

dcommander commented Jul 23, 2019 • edited Loading

dcommander commented Feb 12, 2020

dcommander commented Mar 4, 2020

iskunk commented Apr 10, 2020

dcommander commented Apr 10, 2020

dcommander commented Apr 29, 2020

dcommander commented Aug 9, 2016 •

edited

Loading

dcommander commented Aug 27, 2016 •

edited

Loading

jramos-br commented Aug 12, 2018 •

edited

Loading

tkansgar commented Mar 2, 2019 •

edited

Loading

dcommander commented Jul 23, 2019 •

edited

Loading