Alan: >> 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.
That's great news. That means that, at the very least, the ConsoleKit code should now work better. > I still think it's insane for gdm to have to do getpeerucred() to get It is not a stable interface to use, so in that sense it is a bit insane. However, it is ConsoleKit that does these calls, not GDM. > 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). The issue is that ConsoleKit wants to keep track of all Xservers regardless of how they were started. It was designed so it should work even if the display manager (or whatever program) which launches the Xserver doesn't notify it. So, rather than placing hooks in GDM so that it can tell ConsoleKit this information, ConsoleKit was designed so it can just figure it out by itself. Perhaps, as you say, it would make more sense for ConsoleKit to expect client programs like GDM to notify it with tty information. Or perhaps a more stable interface so that ConsoleKit can just query the Xserver for the information should be created. I think Jon is working on the later. > I've also never really gotten anyone to explain why ConsoleKit is useful > to anyone or why you would possibly want it. Last May, I sent you the following in a private email, so I tried to explain it to you. Perhaps you missed that email, so I'll repeat. Perhaps this info will also benefit others... ---- I think it would be helpful if I explained a bit about how the new ConsoleKit and the GDM rewrite are designed. What complicates things is that we are probably going to use ConsoleKit somewhat differently than it is intended to be used on Linux. But it probably makes sense to explain the Linux model so you can understand how the pieces fit together. On Linux, ConsoleKit is striving to be a utmp/wtmp replacement plus more. It is trying to be a lot smarter and keep track of a lot more information to better support things like user switching and session migration. Since William Jon McCann's background is with FASA, gnome-screensaver, and now GDM, he seems driven to create a unified solution to make these programs all work together. On Linux, they use the pam-ck-connector PAM module so that console login, ssh, telnet, etc. all register session information with ConsoleKit via this PAM module. I understand on Linux that they are moving away from using utmp/wtmp and instead plan to make all programs (e.g. finger, who, etc.) talk to ConsoleKit instead. I believe the reason why ConsoleKit does "odd" things to get information like the device associated with the Xserver is that ConsoleKit is designed to work with independence of the various client programs (such as various display managers). Your suggestion that ConsoleKit does a lot of work to rediscover information that we already have is true, but keep in mind that ConsoleKit is trying to minimize the hooks required to make client programs work with it. So it should function as a utmp replacement even if the user has a display manager that does not directly integrate with it, for example. On Solaris, I anticipate that we will unlikely follow the Linux model, so I think we will likely patch the code to avoid doing some of these "odd" things. For example, I do not anticipate we will use ConsoleKit to replace utmp/wtmp. The main value that ConsoleKit does provide to Solaris is its ability to manage VT switching and session migration. Overall it seems that ConsoleKit and GDM work fairly reasonably to support these features already on Solaris. In other words, it is likely going to be an interface that GDM and the GNOME desktop use as a database to keep track of information about the running graphical sessions started via GDM (whether a session is local or not, what users are associated with which VT's to assist with VT switching, etc.) Especially considering that ConsoleKit is not yet mature, and will likely go through some significant redesign as features like multi-display are added, I have been trying to avoid trying to redesign things too much too early. Instead I have been trying to get the code to work as written with the idea that we will likely redesign aspects of it when the code is more mature and it is easier to see the big picture. In terms of the ck-get-x11-display-device issue [this is the program which uses getpeerucred to figure out the VT associated with the Xserver], we will need to consider whether it makes more sense to try and fix ck-get-x11-display-device or just modify GDM to not use it. It is a little hard to predict the right course right now since multi-display is not yet integrated into ConsoleKit and that will likely affect which approach makes the most sense. Based on some IRC discussions I have had with William Jon McCann, it sounds like he is getting some Linux Xserver people to work with him to more closely integrate ConsoleKit with the Xserver. His plans sound fuzzy, but I wanted to give you a heads up that there seem to be efforts to make ConsoleKit an Xorg dependency in the not too distant future. -- Brian
