On Wed, 2008-09-10 at 14:09 -0400, Kristian Høgsberg wrote: > Everybody can talk to the DRM and create > a token, but only if you can pass it to the server over DRI2 protocol, > can you authenticate.
Oh, so the cookie in the protocol is a client identifier of some kind. In any case, 32 bits of unique id isn't exactly high security; my thought was that we should allow the system to use a longer key to avoid spoofing. > I'd say the two schemes are pretty much equivalent in complexity and > in what options we have for narrowing down access per client as you > suggest. Pros and cons of the two schemes as I see it is that your > scheme eliminates the DRI2Authenticate request from the protocol, but > requires a random cookie to be generated, which is a little icky... > how many bits etc? The old scheme is well established and the extra > request isn't really a concern - it's async. The cookie could be per-X server if there wasn't any desire to provide finer-grained access control. And, 'how many bits' is precisely the question I'd want to leave to the system, but certainly more than 32. > Do we need this? When will the client have a better idea of which > pipe a window is on than the X server? Yes, whenever the two screens overlap. > So for DRI2CopyRegion flags, something like this: > > #define DRI2_VSYNC_DONT_CARE 0x0 > #define DRI2_VSYNC_ABSOLUTE 0x1 > #define DRI2_VSYNC_RELATIVE 0x2 > ( #define DRI2_VSYNC_RESERVED 0x3 ) Sounds good to me. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg