Alan:
>>> # Boolean. Set to "true" if the active session, "false otherwise"
>>> is_active=false
>>
>> "the" active session? On a multi-seat or Sun Ray system, is it okay that
>> there are multiple active sessions?
I updated the comment in the onepager so it now says:
# Boolean. Set to "true" if the session is active, "false otherwise"
# For example, useful to keep track of which VT session is the active
# one.
Which is hopefully now more clear.
>>> /var/svc/manifest/system/consolekit.xml Uncommitted SMF
>>> integration
>>> file.
>>
>> The SMF manifest (*.xml file) should be a Project Private
>> implementation detail.
>> The public interface you're missing here is the FMRI - that's the
>> interface the
>> rest of the system needs to use to control your service, and thus the
>> one you
>> need to include in your interface table.
>
> Okay, I will also make this change to the onepager tomorrow.
Updated. The Exported Interface table now has these lines:
svc:/system/consolekit:default Uncommitted ConsoleKit
FMRI
/var/svc/manifest/system/consolekit.xml Project SMF manifest
Private integration
>>> + /usr/lib/ck-collect-session-info --uid UID --pid PID
>>>
>>> This program is passed the UID and PID of a process, and it returns
>>> the following information from the ConsoleKit database about that
>>> process.
>>>
>>> + /usr/lib/ck-get-x11-server-pid
>>>
>>> Returns the PID of the Xserver process running on the current
>>> $DISPLAY environment variable.
>>
>> What happens if the X server is running in a different zone/label than
>> the
>> client? (For instance, on a Trusted Extensions system, the X server runs
>> in the global zone, labeled clients in non-global, per-label zones.)
>> Is there a ConsoleKit daemon per zone?
>
> In this case, parts of the ConsoleKit framework would not work,
> including this program.
>
> However, since the parts of the ConsoleKit framework which would break
> are only used to support VT switching on the console, I do not believe
> this would be a problem. Clients in a trusted environment would not be
> using VT switching, or using the console.
I also tried to make this more clear in the onepager. See attached
diff file.
>>> GDM uses the ck-get-x11-display-device application to get the
>>> x11-display-device value. When a display is running via graphical VT,
>>> ConsoleKit uses the following mechanism to get the TTY value. This
>>> mechanism works on other operating systems, such as Linux, and also
>>> works on Solaris when VT is being used. When VT is used, these
>>> programs make use of proc interfaces to collect some of this
>>> information, as follows:
>>>
>>> The ConsoleKit ck-get-x11-display-device, ck-get-x11-server-pid, and
>>> ck-collect-session-info programs call XOpenDisplay on a given $DISPLAY,
>>> and then calls ConnectionNumber to get the socket associated with
>>> that display. getpeerucred is used to get the UID and PID of the
>>> process.
>>
>> This still seems highly silly, given that gdm can get the pid of the
>> Xserver
>> by simply checking the variable into which it put the return value
>> from the
>> fork() call it made to start the X server.
Note that ConsoleKit does not store the PID of the X server in its
database. It only uses the PID to get other information about the
process, such as the display-device.
> I will touch base with the upstream ConsoleKit maintainers and get a
> more official response to this design choice before responding.
After talking with the upstream maintainers, they provide the following
reason why ConsoleKit works this way.
This design prevents the session leader from providing spoofed
information. Since the D-Bus OpenSession interface is an unprivileged
operation and takes no arguments. When this is used, the entries in
the database are filled via doing such probing. The session leader can
use the OpenSessionWithParameters and pass in the arguments, and thus
avoid ConsoleKit from needing to do such probing.
In fact GDM does use OpenSessionWithParameters, but GDM also calls the
ck-x11-get-display-device script to figure out what display device
is associated with the display and should be passed into
OpenSessionWithParameters. When using VT, ck-x11-get-display-device
does probe the Xserver to get the VT device name.
Brian
