Are we ready for X server 1.9?

[Eamon Walsh]

On 08/23/2010 11:22 AM, Adam Jackson wrote:
> On Fri, 2010-08-20 at 17:08 -0700, Keith Packard wrote:
>
>   
>> As for the midispcur bugs, I'd like to suggest that damage records lose
>> their ability to hold private storage; it's not currently used
>> anywhere. That's an ABI change though, so not suitable for 1.9 (or 1.9.1).
>>     
> In the absence of XACE, Damages seem like Regions; I can't imagine
> anything interesting a DDX subsystem would want to attach to a Damage.
>
> As a security question it's a little weirder.  The thing you could do
> there is selectively control which bits of damage are reported to the
> listening client.  I'm not sure that's a useful thing to constrain?
> Maybe you want a more-secure app to be able to render over less-secure
> apps without them knowing, but that's just a race you're going to lose
> the next time the less-secure app redraws.  Seems like what you really
> want there is preventing rendering, not preventing knowing about
> rendering; in which case all the information you need about whether to
> allow a Damage to be created is there up-front and doesn't need a
> devprivate.
>
> - ajax
>   

I'm OK with taking out the damage devprivates.  The dixLookupDrawable()
calls in ProcDamageCreate and ProcDamageAdd check for client permission
to touch the drawable (although not sure if the "read" and "write"
access modes currently used are appropriate since it's not really
reading or writing the drawable contents, as you note).

The SELinux code doesn't even use the damage devPrivates right now
because there is no offset registered in dix/privates.c for the damage
type.  dixLookupPrivateOffset() returns -1 which causes SELinux to fall
back on the owning client's devPrivates instead.  You don't want this
for things like windows where you'd like to be able to have the window's
security context be different from the client itself, but for damage
resources it should be fine.

-- 

Eamon Walsh 
National Security Agency