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

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.

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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.

from turbovnc.

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

from turbovnc.

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.

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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!

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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

from turbovnc.

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

from turbovnc.

@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

from turbovnc.

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

from turbovnc.

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.

from turbovnc.

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.

from turbovnc.

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.

from turbovnc.