On Mon, 7 Sep 2020 17:53:46 +0200 Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > 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) Thanks, I'll keep that in mind. Going through logind will exercise the logind-only code in Weston, and sometimes that is good to test. OTOH, I can VT-switch to an unused tty and run Weston like normal. It's all about convenience, particularly with 'git rebase -i --exec' to run tests every commit. > > 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... Appreciated. My use cases are all about developer testing, so they may be fine as hacks. There are more use cases: https://gitlab.freedesktop.org/wayland/weston/-/issues/132 https://gitlab.freedesktop.org/wayland/weston/-/issues/401 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/438 Starting Weston via ssh is something developers use for testing on embedded boards. Sounds like starting Weston in a container is also a new developer use case. There exists curiosity towards CONFIG_VT=n systems too. This is for your information just in case you or someone might find it interesting. If not, no worries. Thanks, pq
Attachment:
pgpM616USTvz6.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
