Automatically choosing a VT for DRM compositor?

[Pekka Paalanen]

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?

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 --------------
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/wayland-devel/attachments/20171030/228825b5/attachment.sig>