Brian Cameron wrote:
> For example, there is a known issue with the way ConsoleKit gets the TTY
> associated with Xservers. Currently it opens a connection to the
> Xserver, uses getpeerucred to get the pid associated with the Xserver
> process, and digs around in /proc to get the associated TTY value. This
> no longer works since they changed the Xserver on Solaris to use named
> pipes instead of sockets, and getpeercred doesn't work with named pipes.
> In addition, Alan Coopersmith has suggested that we not use this
> unstable interface and find something more sane to use. That's just
> one example.
The Xserver on Solaris has supported both named pipes & Unix sockets
since Solaris 2.6 and continues to do so - there was a bug in which
libX11 chose by default in Nevada builds 85-93, but that's fixed now,
and there was a simple workaround you could use of setting DISPLAY
to force the choice in the builds it was choosing pipes instead of sockets.
I still think it's insane for gdm to have to do getpeerucred() to get
the Xserver pid when it started the Xserver and can just look in the
variable it stored the child pid returned by fork(), and that the tty
associated with the Xserver process is meaningless (good luck finding
a tty associated with any Sun Ray server, Xvfb, Xnest or Xephyr - but
as long as ConsoleKit is really about the machines local console, not
other X sessions, I guess that doesn't matter).
I've also never really gotten anyone to explain why ConsoleKit is useful
to anyone or why you would possibly want it.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
