From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Peres Subject: Re: Rendering when dropped master Date: Fri, 20 Dec 2013 10:59:02 +0100 Message-ID: <52B414E6.5010004@free.fr> References: <52B3EA56.5050206@vmware.com> <52B40E7D.6010008@free.fr> <52B41416.2030305@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1E3AFF9D77 for ; Fri, 20 Dec 2013 01:59:09 -0800 (PST) Received: from [192.168.1.101] (unknown [89.157.37.96]) (Authenticated sender: martin.peres) by smtp1-g21.free.fr (Postfix) with ESMTPA id 1B61F940123 for ; Fri, 20 Dec 2013 10:58:59 +0100 (CET) In-Reply-To: <52B41416.2030305@vmware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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