Darren and Gary: >> On some Linux systems, the pam_ck_connector is used to ensure that >> non-graphical logins (e.g. telnet, ssh, etc.) are registered with >> ConsoleKit. Thus ConsoleKit can be used as a utmp/wtmp replacement >> since it stores a superset of the information as in the utmp/wtmp >> database. However, this is not an appropriate use of PAM and there are >> no plans to support this feature on Solaris since there is no >> immediate need to replace utmp/wtmp at this point in time. Instead, >> GDM will make use of ConsoleKit to manage its displays. > > I don't understand why you think this isn't appropriate use of PAM.
I discussed this with Gary Winiger several months ago and he seemed insistent that this was an inappropriate use of PAM. He said that if we wanted programs to integrate with ConsoleKit, they should integrate directly (as GDM does), and not use a PAM module for this purpose. If my understanding of Gary's concerns are correct, he seemed to feel that PAM was to be used for authorization purposes, and not to keep random databases up to date. I've cc:ed Gary. Hopefully he can elaborate his views on this. Unless I am confused it seems that you and he have different perspectives on this. > It > sounds perfectly reasonable use of a PAM session module. The fact that > we don't currently update utmpx/wtmpx/lastlog properly from > pam_unix_session is a bug (ironically we used to do it in 2.5.1 before > PAM became public in 2.6). pam_ck_connector looks like a nicely written > and very useful PAM module. > > I don't think this should replace utmpx/wtmpx on OpenSolaris systems but > I have no problem with it augmenting them. While ConsoleKit does aim to replace utmpx/wtmpx, the practical reason for providing pam-ck-connector is to make sure that programs on Linux which depend on ConsoleKit work. However, on Solaris, we do not deliver any of the programs which use ConsoleKit that benefit from providing this PAM module. On Linux, this PAM module is needed because some components (such as PolicyKit and PulseAudio) use ConsoleKit to check if the user is on the console and grant the user certain authorizations if they are. For example, without this PAM module, users who login to the console would not be able to use audio since PulseAudio would otherwise not be able to tell the user is logged into the console. However, on Solaris, we do not ship PulseAudio, PolicyKit, or any other modules which use ConsoleKit to determine if the user is on the console. On Solaris, we use a very different mechanism for granting such privilege (RBAC and PSARC 2008/034 Defining Workstation Owner Infrastructure). So, pam-ck-connector is currently not really needed on Solaris. If, in the future, we integrate modules which need this PAM module, then we could explore adding it. Though, perhaps it would make more sense to directly integrate such modules directly with RBAC and PSARC 2008/034 rather than using ConsoleKit to tell if the user should gain authorizations if they are on the console. As you say, though, we could deliver the PAM plugin anyway and simply not make use of it in any default PAM stack. There may be some usefulness in doing this. For example, if someone wants to build and use PolicyKit or PulseAudio on OpenSolaris, or if they just want to use ConsoleKit as a utmp/wtmp replacement, then this PAM module could be useful. > I highly recommend that we ship pam_ck_connector. It is quite a > different issue of wither or not we choose to have it configured in any > of the default PAM stacks we provide in /etc/pam.conf. What do others think? I do not have a problem providing the PAM module, but not using it any default PAM stacks if that's what ARC thinks is best. >> ConsoleKit source code contains the programs >> /usr/sbin/ck-log-system-start, /usr/sbin/ck-log-system-restart, and >> /usr/sbin/ck-log-system-stop. These are intended to be helper tools to >> log system start, restart, and stop events. These are intended to make >> ConsoleKit more like utmp/wtmp which also logs these events. Since >> there are no plans to support ConsoleKit as a utmp/wtmp replacement, >> these programs are not included with the Solaris ConsoleKit packages. > > I think they should be delivered. For these helper scripts to be useful, programs that actually shutdown, restart, and stop the machine need to call these helper scripts. On Fedora Linux, they modified upstart (their version of "init") to call these scripts at the appropriate time. Is there really any value in providing these helper scripts before we plan to make Solaris init integrate with them? Note that the only consumer of the start/stop/restart ConsoleKit database entries is the ConsoleKit exported interface /usr/bin/ck-history. So, there is no problem if we do not deliver the helper scripts. The only thing this affects is that when you run ck-history, you do not see information about when the system started, stopped or restarted. >> 4.1.6 Stop/Restart Scripts >> >> ConsoleKit manages stopping and restarting the system. On Solaris, when >> the display manager informs ConsoleKit that such an action is requested, >> the chkauthattr function is called to see if the calling user has RBAC >> permissions for the "solaris.system.shutdown" key. If yes, then the >> /usr/lib/ConsoleKit/scripts/ck-system-restart script is run if a restart >> action was requested. If a shutdown action was requested, then the >> /usr/lib/ConsoleKit/scripts/ck-system-stop script is run. >> >> On Solaris, the ck-system-stop script runs "/sbin/init 5" and the >> ck-system-restart script runs "/sbin/init 6". > > Why does it use init rather than shutdown which is uses on Linux and > FreeBSD ? Rich McAllister said we should do this. Refer to the mail log for LSARC 2004/713: http://sac.eng.sun.com/arc/LSARC/2004/713/mail And search for "init 5" or "init 6" In summary he said: > I'd stay away from the reboot and halt commands, these are migrated > from the old SunOS4 compatibility and don't really do everything > you'd want. I'd go for either the SVR4-ish shutdown (not the /usr/ucb > one, even though most people prefer it) or just go straight to > /usr/sbin/init > the main difference between "shutdown" and "init" is that shutdown > does a "wall" to notify time sharing users. Since rebooting/shutting > down from the login screen really only makes sense on a single-user > system, there doesn't seem to be much use for the "wall". However, we could switch to using shutdown if that makes better sense now. >> 4.1.9 SMF integration >> >> ConsoleKit includes SMF integration files to start and stop the >> /usr/sbin/console-kit-daemon program as a service. >> >> 4.2. Interfaces: >> Exported Interfaces Stability Comments >> --------------------------------------- ----------- ------------- >> SUNWconsolekit Uncommitted Package name. >> SUNWconsolekit-devel Uncommitted Package name. >> SUNWconsolekit-root Uncommitted Package name. >> /usr/lib/pkgconfig/ck-connector.pc Uncommitted pkg-config >> file. >> /var/svc/manifest/system/consolekit.xml Uncommitted SMF >> integration >> file. > > What is the FMRI that is the important interface not the filesystem > location of the manifest file. svc:/system/consolekit:default > What is the method_credential section in the manifest for starting > consolekit ? It currently doesn't have one. You can see the manifest file, it is attached if you have any suggestions for improving it. I based this manifest on the gdm.xml file, which also doesn't have any method_credential sections. Perhaps that was incorrect? >> 4.4. Packaging & Delivery: >> SUNWconsolekit, SUNWconsolekit-root, SUNWconsolekit-devel - packages >> for ConsoleKit. > > Does this project intent to integrate before or after the SXCE demise ? > If after then I see no reason to have SUNWconsolekit and > SUNWconsolekit-root split apart since whey will just get recombined. I am not sure. Obviously the Desktop time will not bother splitting the package if there is no need. Brian