On Fri, Oct 18, 2019 at 3:43 PM Pekka Paalanen <ppaalanen@xxxxxxxxx> 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. > > (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.) So the rules are (if I'm not making a mistake) - If you're not CAP_SYS_ADMIN you can't get/drop_master. - This is a bit awkward, since non-root can become a master, when there's no other master right at this point. So if you want to be able to do this, we should probably clarify this part of the uapi somehow (either de-priv drop_master or make sure non-root can't become master, but the latter probably will break something somewhere). Plus igts to lock down this behaviour. Note that if logind does a vt switch there's a race window where no one is master and you might be able to squeeze in. So perhaps we do want to stop this behaviour and require CAP_SYS_ADMIN to become master, even accidentally. - I thought you can always re-open your own fd through proc? Which should be good enough for this use-case here. - Non-master primary node should indeed give you all the GET* ioctls for kms, and nothing else useful or at least dangerous (you might be able to render with that thing). Just make sure you dont authenticate that new fd. Again maybe we should clarify our docs a bit to make this use case official. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
