* Rendering when dropped master
@ 2013-12-20 6:57 Thomas Hellstrom
2013-12-20 9:31 ` Martin Peres
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Hellstrom @ 2013-12-20 6:57 UTC (permalink / raw)
To: dri-devel@lists.freedesktop.org
So this is a potential issue that needs to be brought up sooner or later:
Let's say a client is authenticated by the current master.
Then the master drops, and we have a new master (fast user switching for
example).
What's the status of the clients authenticated by old masters?
Should they be allowed to render and use memory resources or shouldn't they?
A typical example where this could pose a problem is where user 1 opens
a drm connection, authenticates itself and then drops master.
Then user 2 starts an X server and exposes all DRI contents to user 1?
/Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Rendering when dropped master
2013-12-20 6:57 Rendering when dropped master Thomas Hellstrom
@ 2013-12-20 9:31 ` Martin Peres
2013-12-20 9:55 ` Thomas Hellstrom
0 siblings, 1 reply; 4+ messages in thread
From: Martin Peres @ 2013-12-20 9:31 UTC (permalink / raw)
To: dri-devel
On 20/12/2013 07:57, Thomas Hellstrom wrote:
> So this is a potential issue that needs to be brought up sooner or later:
>
> Let's say a client is authenticated by the current master.
> Then the master drops, and we have a new master (fast user switching for
> example).
>
> What's the status of the clients authenticated by old masters?
> Should they be allowed to render and use memory resources or shouldn't they?
>
> A typical example where this could pose a problem is where user 1 opens
> a drm connection, authenticates itself and then drops master.
> Then user 2 starts an X server and exposes all DRI contents to user 1?
>
> /Thomas
I wouldn't worry about that since all clients should use render nodes
instead.
If you worry about this, help making the switch to them happen.
Martin/mupuf
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Rendering when dropped master
2013-12-20 9:31 ` Martin Peres
@ 2013-12-20 9:55 ` Thomas Hellstrom
2013-12-20 9:59 ` Martin Peres
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Hellstrom @ 2013-12-20 9:55 UTC (permalink / raw)
To: dri-devel
On 12/20/2013 10:31 AM, Martin Peres wrote:
> On 20/12/2013 07:57, Thomas Hellstrom wrote:
>> So this is a potential issue that needs to be brought up sooner or
>> later:
>>
>> Let's say a client is authenticated by the current master.
>> Then the master drops, and we have a new master (fast user switching for
>> example).
>>
>> What's the status of the clients authenticated by old masters?
>> Should they be allowed to render and use memory resources or
>> shouldn't they?
>>
>> A typical example where this could pose a problem is where user 1 opens
>> a drm connection, authenticates itself and then drops master.
>> Then user 2 starts an X server and exposes all DRI contents to user 1?
>>
>> /Thomas
> I wouldn't worry about that since all clients should use render nodes
> instead.
> If you worry about this, help making the switch to them happen.
>
OK, so let's say user 1 opens a connection through a render node and
starts rendering using shared buffers.
Then we do a fast user switch, the render node ACL is updated and user 2
logs in.
What's stopping user 2 from accessing user 1's DRI content?
I haven't looked closely at what's actually allowed through render
nodes; perhaps buffer sharing using global names isn't?
/Thomas
> Martin/mupuf
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Rendering when dropped master
2013-12-20 9:55 ` Thomas Hellstrom
@ 2013-12-20 9:59 ` Martin Peres
0 siblings, 0 replies; 4+ messages in thread
From: Martin Peres @ 2013-12-20 9:59 UTC (permalink / raw)
To: dri-devel
On 20/12/2013 10:55, Thomas Hellstrom wrote:
> On 12/20/2013 10:31 AM, Martin Peres wrote:
>> On 20/12/2013 07:57, Thomas Hellstrom wrote:
>>> So this is a potential issue that needs to be brought up sooner or
>>> later:
>>>
>>> Let's say a client is authenticated by the current master.
>>> Then the master drops, and we have a new master (fast user switching for
>>> example).
>>>
>>> What's the status of the clients authenticated by old masters?
>>> Should they be allowed to render and use memory resources or
>>> shouldn't they?
>>>
>>> A typical example where this could pose a problem is where user 1 opens
>>> a drm connection, authenticates itself and then drops master.
>>> Then user 2 starts an X server and exposes all DRI contents to user 1?
>>>
>>> /Thomas
>> I wouldn't worry about that since all clients should use render nodes
>> instead.
>> If you worry about this, help making the switch to them happen.
>>
> OK, so let's say user 1 opens a connection through a render node and
> starts rendering using shared buffers.
> Then we do a fast user switch, the render node ACL is updated and user 2
> logs in.
> What's stopping user 2 from accessing user 1's DRI content?
>
> I haven't looked closely at what's actually allowed through render
> nodes; perhaps buffer sharing using global names isn't?
That's right. GEM buffer sharing is disabled in render nodes.
Only DMA-Buf is allowed.
GEM buffer sharing could hardly be less secure, that's why it was
decided to drop it entirely in favour of dma-buf.
Martin
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-12-20 9:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-20 6:57 Rendering when dropped master Thomas Hellstrom
2013-12-20 9:31 ` Martin Peres
2013-12-20 9:55 ` Thomas Hellstrom
2013-12-20 9:59 ` Martin Peres
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.