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@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
