[PATCH v7] unstable/drm-lease: DRM lease protocol support

[Ville Syrjälä]

On Fri, Oct 18, 2019 at 04:43:29PM +0300, Pekka Paalanen wrote:
> On Fri, 18 Oct 2019 07:54:50 -0400
> "Drew DeVault" <sir at cmpwn.com> wrote:
> 
> > On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote:
> > > One thing I did not know the last time was that apparently
> > > systemd-logind may not like to give out non-master DRM fds. That might
> > > need fixing in logind implementations. I hope someone would step up to
> > > look into that.
> > >
> > > This protocol aims to deliver a harmless "read-only" DRM device file
> > > description to a client, so that the client can enumerate all DRM
> > > resources, fetch EDID and other properties to be able to decide which
> > > connector it would want to lease. The client should not be able to
> > > change any KMS state through this fd, and it should not be able to e.g.
> > > spy on display contents. The assumption is that a non-master DRM fd
> > > from a fresh open() would be fine for this, but is it?  
> > 
> > What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the
> > path to the device file, and then I open() it and use
> > drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems
> > to work correctly in practice.
> 
> That is nice.
> 
> Personally I'm specifically worried about a setup where the user has no
> access permissions to open the DRM device node directly, as is (or
> should be) the case with input devices.
> 
> However, since DRM has the master concept which input devices do not,
> maybe there is no reason to prevent a normal user from opening a DRM
> device directly. That is, if our assumption that a non-master DRM fd is
> harmless holds.

If there is no master then the first guy to open the device
automagically becomes the master. Maybe a theoretical DoS
vector if you can sneak in and open the device between
dropmaster/setmaster?

-- 
Ville Syrjälä
Intel