Bug 452156 - [EASYFIX PATCH] ck-xinit-session is not executed in /etc/X11/xdm/Xsession
[EASYFIX PATCH] ck-xinit-session is not executed in /etc/X11/xdm/Xsession
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Søren Sandmann Pedersen
Fedora Extras Quality Assurance
: Patch
: 446143 (view as bug list)
Depends On:
Blocks: K12LTSP 237621 F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2008-06-19 13:34 EDT by Adam Tkac
Modified: 2014-06-18 05:10 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 10:16:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch (503 bytes, patch)
2008-06-19 13:44 EDT, Adam Tkac
no flags Details | Diff
run ck-xinit-session for all sessions where the xdg cookie isn't already set (3.79 KB, patch)
2008-07-05 09:16 EDT, Patrice Dumas
no flags Details | Diff
run ck-xinit-session for all sessions where the xdg cookie isn't already set, minor fixes (5.47 KB, patch)
2008-07-09 17:09 EDT, Patrice Dumas
no flags Details | Diff
run run ck-xinit-session for all sessions where the xdg cookie isn't already set, minor fixes (6.87 KB, patch)
2008-09-17 11:45 EDT, Patrice Dumas
no flags Details | Diff

  None (edit)
Description Adam Tkac 2008-06-19 13:34:42 EDT
Description of problem:
/usr/bin/ck-xinit-session is not executed in /etc/X11/xdm/Xsession. It causes
that audio doesn't work in session.

Version-Release number of selected component (if applicable):
$ rpm -q xorg-x11-xdm
xorg-x11-xdm-1.1.6-3.fc9.x86_64

How reproducible:
always

Steps to Reproduce:
1. $ cat /etc/sysconfig/desktop 
DISPLAYMANAGER=XDM
PREFERRED=/usr/bin/startfluxbox
2. login to X session
3. run xmms (for example) - error (pulseaudio says something about permission
denial)
  
Actual results:
sound doesn't work

Expected results:
sound works as expected

Additional info:
I solved problem with attached patch in my case. I think that ck-xinit-session
should be also called on other places in /etc/X11/xdm/Xsession
Comment 1 Adam Tkac 2008-06-19 13:41:01 EDT
Changed component to xorg-x11-xinit because /etc/X11/xdm/Xsession is symlink to
/etc/X11/xinit/Xsession
Comment 2 Adam Tkac 2008-06-19 13:44:56 EDT
Created attachment 309866 [details]
patch

this patch solves problem in my case
Comment 3 Patrice Dumas 2008-06-20 03:51:24 EDT
Doesn't it conflict with gnome/kde having already started the session
(with failsafe/custom on the command line)?

Using something similar than what is done in xinitrc-common 
for SSH_AGENT by looking if XDG_SESSION_COOKIE is set should 
certainly do the trick, however. 

As a side note, could kdm and gdm avoid starting the consolekit 
session in their code but instead do like xdm? 

Maybe this is not possible due to fast user switching, but if 
it is possible it seems better than the 
existing code which has to find the X device. (of course something
has to find the X device, but I think that it is better if it
is done at only one place, in consolekit and that consolekit hides
the non portable stuff).

Also $CK_XINIT_SESSION should be added at all the places where
SSH_AGENT is called, such that it works for display manager that
call Xsession with an argument (like wdm).


It is nice if it works that way, when I looked at this issue I
mistakenly thought that one had to be root to start the session
which lead to a rather complicated implementation. 
Comment 4 Adam Tkac 2008-06-20 04:31:39 EDT
(In reply to comment #3)
> Doesn't it conflict with gnome/kde having already started the session
> (with failsafe/custom on the command line)?

I think no. I'm not using kde/gnome

> Using something similar than what is done in xinitrc-common 
> for SSH_AGENT by looking if XDG_SESSION_COOKIE is set should 
> certainly do the trick, however. 
> 
> As a side note, could kdm and gdm avoid starting the consolekit 
> session in their code but instead do like xdm? 

I think that gdm/kdm doesn't start code inside. Main difference between gdm/kdm
and xdm is that xdm starts session with /etc/X11/xdm/Xsession and kdm/xdm uses
/etc/X11/xinit/xinitrc.

In xinitrc is consolekit successfully started but in Xsession that command missing.

> 
> Also $CK_XINIT_SESSION should be added at all the places where
> SSH_AGENT is called, such that it works for display manager that
> call Xsession with an argument (like wdm).

You are absolutely right. I used attached patch as example which solves problem
for me ;)

When you execute ck-list-sessions inside session you have to see active CK
session. If not then your audio cannot work.
Comment 5 Patrice Dumas 2008-06-20 05:21:23 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > Doesn't it conflict with gnome/kde having already started the session
> > (with failsafe/custom on the command line)?
> 
> I think no. I'm not using kde/gnome

Unless I am wrong, kdm/gdm starts the consolekit session in their
code before running /etc/X11/xinit/Xsession. If custom is used, 
then, still unless I am wrong, the line you modify in your
patch will be used but with the session already started.


> > As a side note, could kdm and gdm avoid starting the consolekit 
> > session in their code but instead do like xdm? 
> 
> I think that gdm/kdm doesn't start code inside. 

They did. the kdm patch is a fedora specific patch, while it is in 
upstream gdm, if I'm not wrong.

> Main difference between gdm/kdm
> and xdm is that xdm starts session with /etc/X11/xdm/Xsession and kdm/xdm uses
> /etc/X11/xinit/xinitrc.

I don't think so. Since /etc/X11/xdm/Xsession is a symlink to 
/etc/X11/xinit/Xsession, all use that file.


> In xinitrc is consolekit successfully started but in Xsession that command
missing.

Indeed, but it should be done carefully considering that other dm don't
necessary do the same nor have the same issues.
Comment 6 Patrice Dumas 2008-07-05 09:16:55 EDT
Created attachment 311066 [details]
run ck-xinit-session for all sessions where the xdg cookie isn't already set

I have put a changelog entry to have a ready to use patch, it 
can be removed.

As a side note, it is so easy that it is very strange that it
hasn't been done already.
Comment 7 Adam Tkac 2008-07-07 11:08:59 EDT
(In reply to comment #6)
> Created an attachment (id=311066) [edit]
> run ck-xinit-session for all sessions where the xdg cookie isn't already set

works fine for me.

> As a side note, it is so easy that it is very strange that it
> hasn't been done already.

I think this is only xdm problem and only few people using it so this problem
wasn't discovered
Comment 8 Patrice Dumas 2008-07-09 17:09:07 EDT
Created attachment 311422 [details]
run ck-xinit-session for all sessions where the xdg cookie isn't already set, minor fixes

An updated patch that also updates to 1.0.9, otherwise there are
update issues. Also other minor issues fixed (versioned obsoletes, 
license) and also fix Bug 413041.
Comment 9 Patrice Dumas 2008-07-11 08:26:37 EDT
(In reply to comment #7)
> (In reply to comment #6)

> > As a side note, it is so easy that it is very strange that it
> > hasn't been done already.
> 
> I think this is only xdm problem and only few people using it so this problem
> wasn't discovered

It is not really strictly xdm issue. This could be used for kdm
and gdm too, avoiding having to patch the display manager, keeping
modularity and putting platform specific stuff (the device detection)
in only one place (consolekit) instead of in the dm which should ignore
such thing and use only X. But that's just my opinion and it looks like
the design of these dbus stuff is different.
Comment 10 Kevin Kofler 2008-07-12 12:02:26 EDT
This looks like the wrong solution to me, Xsession doesn't have the information 
the display manager has, so ConsoleKit will get provided with incomplete 
information if you do it that way.
Comment 11 Patrice Dumas 2008-07-13 06:12:20 EDT
What information is missing? The xdmcp information indeed could 
stay in the dm, but xinit already uses consolekit that way, so 
if something is missing it will also be missing in xinit. Anyway here
is what ck-list-sessions give to me. What is missing?

$ ck-list-sessions 
Session2:
        uid = '500'
        realname = 'Patrice Dumas'
        seat = 'Seat1'
        session-type = ''
        active = TRUE
        x11-display = ':0'
        x11-display-device = '/dev/tty7'
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2008-07-13T09:58:07.044968Z'
Comment 12 Kevin Kofler 2008-07-13 10:03:37 EDT
That looks OK (for a local session), but I'm pretty sure it isn't going to work 
with XDMCP.
Comment 13 Patrice Dumas 2008-07-13 10:11:43 EDT
(In reply to comment #12)
> That looks OK (for a local session), but I'm pretty sure it isn't going 
> to work with XDMCP.

Sure. That part should certainly stay in the dm.
Comment 14 Kevin Kofler 2008-07-13 10:18:21 EDT
At that point, what do we gain over doing everything in the DM?

My plan is to put your version of the KDM patch (the one which uses 
libck-connector) in Rawhide for testing, and if it works fine, fight for 
getting it accepted in upstream KDE for 4.2. The licensing objections ossi had 
should be resolved (there's no GPL code in your version of the patch, the 
equivalent code is now in libck-connector and that library is X11-licensed like 
the KDM backend is), so I think it should be mergeable.
Comment 15 Patrice Dumas 2008-07-13 11:39:54 EDT
(In reply to comment #14)
> At that point, what do we gain over doing everything in the DM?

A better design. In fact it would have been much better if the consolekit
stuff had been done in the framework of existing technologies 
(pam/X/Xdmcp/whatever) as much as possible, instead of doing it in 
the framework of gdm only and thinking about integration afterwards or 
ignoring other possibilities. In my opinion XDMCP integration should have 
been plannified from the beginning, maybe there are other possibilities
than putting it in the dm that are more modular and less specific.

> I think it should be mergeable.

In my opinion only the xdmcp part should be merged, the device selection
is too ugly to be acceptable in a cross-platform software. But I am not 
the kdm maintainer...
Comment 16 Adam Tkac 2008-07-16 06:47:26 EDT
(In reply to comment #15)
> > I think it should be mergeable.
> 
> In my opinion only the xdmcp part should be merged, the device selection
> is too ugly to be acceptable in a cross-platform software. But I am not 
> the kdm maintainer...
> 

I think this solution will be the best. One other bug is bug #446143. When you
open vnc session CK session is not opened due this bug. We should keep generic
things on one place.
Comment 17 Adam Tkac 2008-07-21 10:54:10 EDT
*** Bug 446143 has been marked as a duplicate of this bug. ***
Comment 18 Patrice Dumas 2008-09-17 11:45:27 EDT
Created attachment 316982 [details]
run run ck-xinit-session for all sessions where the xdg cookie isn't already set, minor fixes

This is rebased.

Please have a look at it, I can't control myself and keep on adding 
packaging fixes...
Comment 19 Patrice Dumas 2008-09-28 09:02:49 EDT
What should be done to have it applied? It would be nice to have it in 
F-10, such that xdm/wdm/... work in that release.

I have posted a patch more than 2 months ago!
Comment 20 Warren Togami 2008-09-28 10:51:02 EDT
Adding this to F10Blocker because it will be ignored otherwise.
Comment 21 Matthias Clasen 2008-10-01 20:35:48 EDT
While I disagree in principle with all the Xsession shellscript madness, the last patch looks like it could be applied without any problems.
Comment 22 Kevin Kofler 2008-10-02 00:27:32 EDT
FWIW, I also think patching the DMs is the better solution. I've been doing that with KDM for a long time now.
Comment 23 Jesse Keating 2008-10-24 20:32:06 EDT
(In reply to comment #20)
> Adding this to F10Blocker because it will be ignored otherwise.

Looks like it got ignored anyway.  Now I'm not so sure about making this change at this point in F10's cycle.

Can somebody closer to the problem decide if it's safe enough?
Comment 24 Patrice Dumas 2008-10-27 05:06:01 EDT
It has worked for me for months now, both with xdm and kdm. But since it is 
broken for more than one year, I am not sure than there is a need to hurry, 
I guess that I am the only user still using something else than kdm/gdm.
Comment 25 Ray Strode [halfline] 2008-10-28 11:45:22 EDT
Well this is definitely not a blocker...  removing from blocker list.
Comment 26 Marco Pesenti Gritti 2008-11-29 06:53:24 EST
We run into the same problem with the Sugar livecd which uses slim as login manager.
Comment 27 bob mckay 2008-12-12 20:34:06 EST
Patrice, thank you _very much_ for the patch. However I think your comment #24 way underestimates the importance of this issue. It really isn't just xdm/wdm. Since 446143 has been merged, it also covers vnc (and apparently nx). Googling 'vnc ConsoleKit' will show that this is a widespread problem. But even that way under-estimates the issue, because it only picks up people who realise that ConsoleKit is the root cause of their problems with vnc/nx and whatever application. Most will think - as I initially did - that it's Yet Another Selinux Problem (YASP), and probably give up when a relabel doesn't fix it...
Comment 28 Adam Tkac 2009-02-25 05:20:06 EST
I applied patch in rawhide, fixed in xorg-x11-xinit-1.0.9-5.fc11
Comment 29 Adam Tkac 2009-03-09 11:12:29 EDT
*** Bug 476402 has been marked as a duplicate of this bug. ***

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