On Mo, 07.09.20 11:47, Pekka Paalanen (ppaalanen@xxxxxxxxx) wrote: > > I am not aware of any. > > > > > Any suggestions on what might work? > > > > Other than patching logind with some new concept, no suggestion. Or > > simply bypassing logind and opening the devices directly with root > > privs? or test this in virtualization? > > Thanks for the reply! > > That's a little inconvenient. I was hoping there might be a way > somehow, perhaps even create a new session and become its controller > without elevated privileges if the the seat in question is not "in > use". I could configure the extra DRM device into a non-default seat, > then try taking over that seat. You could open a new PAM session with "systemd-run -p PAMName=", and configure the seat for it via the XDG_SEAT env var. pam_systemd picks up the seat to use via XDG_SEAT env var. (but it will require privs to run systemd-run) > Is that really not possible without some kind of elevated privileges my > normal desktop user doesn't usually have? Could it be allowed via > polkit configuration or something? > > Or maybe I indeed need to forget about logind and open the DRM device > as a normal user. After all, the first one to open a DRM device should > automatically gain DRM master status, and there have been recent kernel > patches to even allow dropping and re-gaining DRM master status without > being root/CAP_SYS_ADMIN IIUC. That won't help with input devices if I > wanted to test anything interactive... but maybe I could allow some > dedicated input devices to be opened by my normal user and make sure I > don't use those for my desktop. > > Right, maybe I can hack it up after forgetting about logind. Put all > those devices into a non-default seat, override their file permissions, > and assume they are untrusted (can be eavesdropped). Note that I myself never worked on a wayland compositor or suchlike, I have no experience with your perspective on these things: we look at this from the other side... Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel