Bug 1149893

Ditto xrdp.

In fact, every time man moves or resizes the x2go client window, authentication request pop-up appears 6 times.

Same thing happens with the TigerVNC viewer.  Resize of the client window with client either KDE or Gnome causes authentication request to create a color managed device, and the window pops up 6 or so times.

Can we get some movement on this?  Are there any security implications around allowing X2Go/VNC/etc sessions to create/manage color devices?

(In reply to Orion Poplawski from comment #4)
> Can we get some movement on this?  Are there any security implications
> around allowing X2Go/VNC/etc sessions to create/manage color devices?

X2Go probably needs to mark the session as active.

(In reply to Richard Hughes from comment #5)
> X2Go probably needs to mark the session as active.

Any docs for how that is done?  Thanks.

Also, I'm not entirely sure that is the proper solution in all cases.  Doesn't making the session active give lots of other authority like being able to shut the machine down, etc?  That may not be desired in many other situations.  But this color thing appears to be unavoidable.

Richard,

Can I somehow circumvent this issue by giving x2go static access rights?

- Gilboa

How about this: Is there any way I can disable the color profile junk which I have no use for? I'm not a photographer or graphic artist. I'm not interested
in accurate color matching of screen an printer. Can't I just make it go away and stop bothering me?

(In reply to Tom Horsley from comment #9)
> How about this: Is there any way I can disable the color profile junk which
> I have no use for?

Ok I edited /usr/share/polkit-1/actions/org.freedesktop.color.policy,
changed every instance of "auth_admin" to "no", restarted colord, and then logged in over x2go and got no prompt for silly color profile nonsense. Time will tell if this sticks around and continues to work.

Of course the next colord update will probably overwrite the policy file and put it back the way it was, so I'll need to add this to my "big hammer" script that runs after every update to re-fix things.

I get the same problem (6 authentication request dialogs in sequence, all for the same thing) when connecting with freenx to the kde desktop (gnome doesn't work at all with freenx). This problem seems to go all the way back to June 2011: https://bugzilla.novell.com/show_bug.cgi?id=698250

Does using colord for a remote session make any sense at all?

Is there a way to implement Tom Horsley's solution in a local polkit file somewhere that overrides the file he edited - so updates don't undo the fix?

Or is there a way to disable colord for remote connections?

Created attachment 1067913 [details]
Screen Cap of the Dialog I get 6 of

This is the dialog I get 6 of every time I connect using freenx to the KDE desktop. I also see the following in logwatch (with username changed to foobar):

polkitd: Operator of unix-session:300 FAILED to authenticate to gain authorization for action org.freedesktop.color-manager.create-device for system-bus-name::1.862 [kdeinit4: kded4 [kdeinit]] (owned by unix-user:foobar): 6 Time(s)
polkitd: Operator of unix-session:300 successfully authenticated as unix-user:foobar to gain ONE-SHOT authorization for action org.freedesktop.color-manager.create-device for system-bus-name::1.862 [kdeinit4: kded4 [kdeinit]] (owned by unix-user:foobar): 6 Time(s)

(In reply to Arthur Kahlich from comment #11)
> Is there a way to implement Tom Horsley's solution in a local polkit file
> somewhere that overrides the file he edited - so updates don't undo the fix?

You can place a .rules file in /etc/polkit-1/rules.d

I'm doing in 02-allow-colord.rules:

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("nwra")) {
      return polkit.Result.YES;
   }
});

Which allows users in our group to access colord.

Thank you Orion Poplawski for sharing your rules script. With appropriate modification of the group name on the 'subject.isInGroup("")' condition that rule works as I desire - no more needless authorization required popups.

This is a good work around for me until this is fixed properly. I hope that occurs soon.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Upstream bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=751775

I cannot see this happening with xrdp in F24 any more as of a few weeks back. Also not happening in F25. So, from my perspective, this bug can be closed.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.