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

Reply via email to