[RFC] MPX XInput Protocol extensions - big issues....
Eamon Walsh
ewalsh at tycho.nsa.gov
Tue Mar 4 01:14:06 PST 2008
Jim Gettys wrote:
> Some comments:
>
> Big questions:
>
> How will we associate users with input devices? We'll certainly be
> dealing with input devices that can identify who is using them (e.g.
> Diamond Touch, remote devices, etc.)
>
> How will that interact with Eamon's security framework?
>
The devPrivates mechanism allows security information to be stored in
the device structure, and XACE hooks provide control over which clients
can open a device and which windows can receive events (but see below).
A security extension might offer protocol to allow the security labels
on devices to be changed; this is what the SELinux extension does. Or
it might listen on D-BUS for messages that tell it what to do.
I don't think MPX will be difficult to integrate with XACE. Peter has
done most of the work, and I will help out once it lands.
> I can see (at least) two possibilities:
> 1) events might include a field to identify who owns the device
> 2) we might include the identity of the owner of the device as part of
> the device on query, and identify whenever the owner of a device changes
> as an event.
>
Event delivery is something I'd like to work on. I'd like to be able to
generate a security label at the point where the event is generated and
have that flow down through the server until just before the event is
about to be sent to a client, when a permission check could be done to
decide whether to deliver it. This would work regardless of who has
what grabbed and should work for other types of events besides input
(PropertyNotify, for example). It would also allow piggyback events to
be sent from the security extension containing additional information
about the event.
> Should we introduce the user as a first class object?
>
My goal with XACE is to allow such an object to be implemented in an
extension without any server changes.
I keep meaning to go investigate ConsoleKit and see how it works and
what its notions of session and user are.
> How is this intended to work with ChangeWindowAccess?
>
When MPX lands I'll take a look at this. The functionality it provides
should be offered through an XACE hook for general use.
> Other question:
>
> Xi's valuators lack names, so you don't know whether the first valuator
> is "x", or "y", or "z", or "pressure", etc. Are we intending to fix
> this (major) oversight? If so, how?
>
> Best regards,
> - Jim
>
>
>
>
>
> On Mon, 2008-02-25 at 17:53 +1030, Peter Hutterer wrote:
>
>> I did my homework and wrote up the XI protocol message specifications
>> that will be in the first merged version of MPX (April 08 probably).
>>
>> The document resembles the format used in the X Protocol Reference
>> Manual (Nye, 1994).
>>
>> HTML version: http://people.freedesktop.org/~whot/Xi/
>> PDF version: http://people.freedesktop.org/~whot/Xi/mpx_xi_protocol.pdf
>>
>> Short overview of the new requests:
>> - ListInputDevices
>> + a previously used padding field now specifies the attachment/pairing
>> + use field changed
>> - QueryDevicePointer
>> + same as QueryPointer but specifies the device.
>> - WarpDevicePointer
>> + same as WarpPointer but specifies the device.
>> - ChangeDeviceCursor
>> + specify cursor shape for device
>> - ChangeDeviceHierarchy
>> + create/remove new master devices
>> + change attachment of slave devices
>> - ChangeWindowAccess
>> + change access rules for devices on a given window. useful for
>> multi-user GUIs. Not a security feature!
>> - QueryWindowAccess
>> + query access rules
>> - SetClientPointer/GetClientPointer
>> + set the device that is picked when a core request doesn't specify a
>> device.
>> - XiSelectEvent
>> + select for generic events
>> - ExtendedGrabDevice
>> + grab device, but with generic event masks
>>
>> Short overview of new events
>> - DeviceEnterNotify, DeviceLeaveNotify (well, guess)
>> - DeviceHierarchyChangedEvent
>> + sent as a notification after a ChangeDeviceHierarchy
>> - DeviceClassesChangedEvent
>> + sent when the master flips state to reflect a new slave device.
>>
>> Again, full documents to be found at:
>> HTML version: http://people.freedesktop.org/~whot/Xi/
>> PDF version: http://people.freedesktop.org/~whot/Xi/mpx_xi_protocol.pdf
>>
>> I will try to get a formal review of the core protocol and the behaviour
>> changes of XI out soon. Meanwhile, please review these additions. Thanks!
>>
>>
>> Cheers,
>> Peter
>> _______________________________________________
>> xorg mailing list
>> xorg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
--
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency
More information about the xorg
mailing list