Red Hat Bugzilla – Bug 476402
ConsoleKit/vncserver incompatibility (20081213 software)
Last modified: 2013-04-30 19:42:05 EDT
Description of problem:
VNCserver doesn't seem to connect properly to ConsoleKit (with consequent failures of PackageKit and similar). This may be a consequence of current selinux policies.
Version-Release number of selected component (if applicable):
Nov 20 01:53:01 Installed: vnc-libs-4.1.2-31.fc9.i386
Nov 20 01:53:01 Installed: vnc-server-4.1.2-31.fc9.i386
Dec 14 01:35:05 Updated: vnc-libs-4.1.2-32.fc9.i386
Dec 14 01:35:25 Updated: vnc-server-4.1.2-32.fc9.i386
Nov 20 00:45:57 Updated: selinux-policy-3.3.1-107.fc9.noarch
Nov 20 00:50:57 Updated: selinux-policy-targeted-3.3.1-107.fc9.noarch
Dec 14 01:32:54 Updated: selinux-policy-3.3.1-111.fc9.noarch
Dec 14 01:33:59 Updated: selinux-policy-targeted-3.3.1-111.fc9.noarch
(I'm running targeted/enforcing)
Can't find a way to get ConsoleKit details, but
Steps to Reproduce:
1. Start vncserver
2. Connect over ssh tunnel
3. Run Package installer (or anything else that depends on ConsoleKit)
"Package installer is running when the session is not active" etc.
Package installer runs normally
I normally run vnc over an ssh pipe, but have confirmed that the problem occurs whether the vnc connection is local over a pipe, or direct over port 59xx.
I'm using a stock standard xstartup (see xstartup.txt).
vncserver reports inability to acquire NetworkManagerUserSettings (I think this is the critical one) and some other problems (see vnc_log.txt)
ck-list-sessions reports only two sessions (see sessions.txt), but I don't think they relate to vncserver, as they don't disappear when the server is killed
setroubleshoot reports a problem with ck-get-x11-serv (I assume it's the cause of the above). See sel_ckgetx11serv.pdf
I don't think it's just a labeling problem, as this problem recurred immediately after an autorelabel. However I can't guarantee that the autorelabel was successful, as selinux reported some problems with restorecon at about the time the autorelabel should have been happening (see sel_restorecon.pdf). I can't figure any way to check this.
The problem may possibly be the same as but 466128, but it's hard to tell because
.there isn't enough detail in that bug report to be sure
.anyway, it's against F10 rather than F9
Created attachment 326842 [details]
ConnectKit Sessions Registered at time of problem
Created attachment 326843 [details]
Relevant part of vncserver log
Created attachment 326844 [details]
Created attachment 326845 [details]
setroubleshoot of ck-get-x11-serv (consolekit_t) problem
Created attachment 326846 [details]
setroubleshoot of failed restorecon (possible failed autorelabel?)
*** This bug has been marked as a duplicate of bug 477121 ***
Hope I'm doing this the right way; this bug is _not_ a duplicate of 477121. Recent updates fixed 477121 without fixing this.
The present stage of trying to run ssh-tunneled vncserver and undertake admin tasks is that it fails in two separate ways (FC9 updated to 2009/02/02). Firstly, there is a problem related to 446143 and 452156, namely that consolekit is not called for the vncserver x11 session. This is essentially a problem in the standard xstartup file, which uses:
This means that the ConsoleKit calls supplied by the patch in response to 477121 are applied to the spawned process, not the vncserver x11 process (by the way, this means that the marking of 446143 as a duplicate of 477121 was almost certainly wrong, since the patches almost certainly did not fix 446143 - of course I have no direct way to verify this). I'm not sure that there's any way to fix this that doesn't involve changing the user xstartup files.
However even substituting the xstartup call with the result of what is in the 477121 patch:
exec $CK_XINIT_SESSION $SSH_AGENT /etc/X11/xinit/Xclients || \
exec $CK_XINIT_SESSION $SSH_AGENT /etc/X11/xinit/Xclients
still fails to give the vncserver process console capabilities. My best guess is that this is because of selinux interactions; when we initiate a vncserver session as above, we are still getting selinux violations identical to those reported in 471121 (even though 471121 selinux violations - i.e. relating to starting X11 independent of vncserver - have now gone away).
This is a complete show-stopper for us. We have servers that need to be maintained headlessly; they are currently stuck at F8 and pre-December F9 because of this issue. We are about to install a replacement for the F8 server. Is there any hope of a fix or workaround, or should we be switching to CentOS?
Sorry, got my bug numbering wrong in some of the preceding (right numbers, wrong roles), should have read:
>This means that the ConsoleKit calls supplied by the patch in response to
>452156 are applied to the spawned process, not the vncserver x11 process (by
>the way, this means that the marking of 446143 as a duplicate of 452156 was
>almost certainly wrong, since the patches almost certainly did not fix 446143 -
>of course I have no direct way to verify this). I'm not sure that there's any
>way to fix this that doesn't involve changing the user xstartup files.
> However even substituting the xstartup call with the result of what is in the
> 452156 patch:
I'm not sure if I understand you correctly. Does patch written in https://bugzilla.redhat.com/show_bug.cgi?id=452156#c18 fix your problems? (you don't have to build entire rpm, patch only /etc/X11/xinit/Xsession and /etc/X11/xinit/xinitrc-common files)
*** This bug has been marked as a duplicate of bug 452156 ***
Dear Adam, firstly may I apologise? For some reason, I did not receive notification of the request in comment #10 - it may have got spam-trapped. Hence the delayed reply.
Unfortunately, no, the patch in
doesn't fix the problem. I'm sorry, I don't fully understand the workings of ConsoleKit. But I would guess the problem is this. The standard vncserver ~user/.vnc/xstartup file (which presumably has an active seat) doesn't directly call xinitrc. Instead, it exec's it. Does this mean that the spawned process doesn't inherit the active seat? If so, I think it's probably the explanation: the ConsoleKit call supplied by the patch is applied to a process that already doesn't have an active seat.
It may be that there is no way to fix this short of changing the standard vnc xstartup file (which will break most installations of vnc clients). But even including ConsoleKit calls in the xstartup file doesn't fix the problem, because selinux blocks the calls. Whether there is a secure way of overcoming that problem is way beyond my knowledge.
I'll attempt to remove the "mark duplicate", but not confident I understand bugzilla well enough to do so successfully.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 WONTFIX if it remains open with a Fedora
'version' of '9'.
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 prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.
Thank you for reporting this bug and we are sorry it could not be fixed.