Bug 1149893 - Authentication dialog upon x2go KDE login
Summary: Authentication dialog upon x2go KDE login
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: colord   
(Show other bugs)
Version: 23
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-06 20:31 UTC by Orion Poplawski
Modified: 2017-09-06 02:55 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 12:55:11 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screen Cap of the Dialog I get 6 of (41.31 KB, image/png)
2015-08-28 06:12 UTC, Arthur Kahlich
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 751775 None None None 2016-08-31 16:07 UTC

Description Orion Poplawski 2014-10-06 20:31:39 UTC
Description of problem:

Logging into remote x2go KDE session I get an authentication request to create a color managed device to authenticate as root.  This is unwanted.

Version-Release number of selected component (if applicable):
colord-1.2.3-2.fc21.x86_64

Comment 1 Bojan Smojver 2014-12-14 21:47:11 UTC
Ditto xrdp.

Comment 2 Seb 2015-01-28 08:01:44 UTC
In fact, every time man moves or resizes the x2go client window, authentication request pop-up appears 6 times.

Comment 3 David V 2015-03-26 17:20:50 UTC
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.

Comment 4 Orion Poplawski 2015-06-23 14:35:19 UTC
Can we get some movement on this?  Are there any security implications around allowing X2Go/VNC/etc sessions to create/manage color devices?

Comment 5 Richard Hughes 2015-07-01 11:44:26 UTC
(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.

Comment 6 Orion Poplawski 2015-07-01 14:49:58 UTC
(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.

Comment 7 Orion Poplawski 2015-07-01 14:51:52 UTC
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.

Comment 8 Gilboa Davara 2015-07-28 13:19:52 UTC
Richard,

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

- Gilboa

Comment 9 Tom Horsley 2015-08-24 13:14:09 UTC
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?

Comment 10 Tom Horsley 2015-08-24 20:17:33 UTC
(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.

Comment 11 Arthur Kahlich 2015-08-28 05:51:25 UTC
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?

Comment 12 Arthur Kahlich 2015-08-28 06:12:28 UTC
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)

Comment 13 Orion Poplawski 2015-08-28 14:40:34 UTC
(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.

Comment 14 Arthur Kahlich 2015-08-30 06:04:04 UTC
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.

Comment 15 Fedora End Of Life 2015-11-04 10:40:55 UTC
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.

Comment 16 Pierre Ossman 2015-12-25 10:41:49 UTC
Upstream bug report:

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

Comment 17 Bojan Smojver 2016-11-13 21:29:32 UTC
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.

Comment 18 Fedora End Of Life 2016-11-24 11:15:07 UTC
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.

Comment 19 Fedora End Of Life 2016-12-20 12:55:11 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.