Automatically choosing a VT for DRM compositor?

[Matt Hoosier]

On Mon, Oct 30, 2017 at 9:45 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Mon, 30 Oct 2017 13:45:24 +0000
> "Ucan, Emre (ADITG/ESB)" <eucan at de.adit-jv.com> wrote:
>
> > Hello Matt and Pekka,
> >
> > Actually, we are OK with running weston with a static tty within a
> > systemd service file, but launcher_direct_connect() function is
> > failing when user is not root.
> >
> > Therefore, we patched weston to remove the expilicit check for root
> > user.  I am planning to send this patch to the mailing list.
> >
> > We also updated ownership of drm and tty devices accordingly, so that
> > weston can run as non-root user.
>
> Hi,
>
> IMO that is bad practice. I'll explain why below, since Matt had a
> similar question. There is a reason why launcher-direct requires root.
> It has not been written for anything else.
>
> > > -----Original Message-----
> > > From: wayland-devel [mailto:wayland-devel-
> > > bounces at lists.freedesktop.org] On Behalf Of Matt Hoosier
> > > Sent: Montag, 30. Oktober 2017 14:28
> > > To: Pekka Paalanen
> > > Cc: wayland mailing list
> > > Subject: Re: Automatically choosing a VT for DRM compositor?
> > >
> > > On Mon, Oct 30, 2017 at 5:10 AM, Pekka Paalanen
> > > <ppaalanen at gmail.com> wrote:
> > >
>
> > >
> > >     Does this mean you would only cater for the "run weston as
> > > root" case? ;-)
> > >
> > > No, that wasn't the intent. Running a DRM instance of Weston as a
> > > non-root user doesn't require anything really more than adjusting
> > > ownership on the /dev/tty* character devices so that the VT can be
> > > configured. I.e. a user 'weston' would need added to the 'tty' Unix
> > > group to have permission to run ioctl(/dev/tty0, VT_OPENQRY) and
> > > would also need assigned ownership of /dev/tty[0...7] in order to
> > > do KDSETMODE. Nobody would want to do that on the desktop because
> > > of the security implications, but that seems fine to do on an
> > > embedded system.
>
> You need elevated privileges for:
> - the tty unless already owning the session
> - the DRM KMS device node and DRM master
> - the input devices
>
> All these are preferably handled by an agent like weston-launch or
> logind, because giving weston and therefore usually all graphical
> applications access to them is a security risk. Particularly input
> devices: if Weston can open them, by default there is nothing to
> prevent random apps opening them as well.
>
> You are on embedded, you audit your software, you don't care about
> the above security issues because you don't have input devices or
> no-one can run arbitrary programs or whatever. You can invent your own
> security setups by running weston as one user and jumping through hoops
> to run apps as other users. Running apps as a different user does have
> its merits.
>
> But why would you bother inventing an inferior setup if you use systemd
> already and therefore you have logind where all this has already been
> implemented with security in mind?
>

This discussion seems to hinge on whether logind can be made to work for
Weston as spawned by system units (rather than user-session units). I find
that sd_pid_get_session() has always failed for me (leading to the "logind
not running in a systemd session" Weston log entry).

The documentation on sd_pid_get_session() says:

Note that not all processes are part of a login session (e.g. system
> service processes, user processes that are shared between multiple sessions
> of the same user, or kernel threads).


So both empirically and in documentation, this seems like something that
won't work. Do you have some successful past experience in using logind
with system service processes? I'm not seeing the path to success here for
system units.


>
> Even if you got everything right, I think it shows a bad example to
> others who are not aware of all the caveats you have carefully avoided.
>
> Is there something wrong with logind?
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171031/3e9d0ad8/attachment-0001.html>