[systemd-devel] Logind: how to access a device when you're not the session controller

[Pekka Paalanen]

On Mon, 7 Sep 2020 17:53:46 +0200
Lennart Poettering <lennart at poettering.net> wrote:

> On Mo, 07.09.20 11:47, Pekka Paalanen (ppaalanen at 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)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200908/80e55c99/attachment.sig>