[PATCH v7] unstable/drm-lease: DRM lease protocol support
ppaalanen at gmail.com
Fri Oct 18 13:43:29 UTC 2019
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
(Wayland display servers usually run as a normal user, while logind
or another service runs with elevated privileges and opens input and
DRM devices on behalf of the display server.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the dri-devel