On Mo, 07.09.20 11:47, Pekka Paalanen (ppaala...@gmail.com) 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to