[kbd] openvt and virtual terminals

[Ken Moffat]

On Wed, Sep 18, 2019 at 05:30:47PM +0200, Christoph Pleger wrote:
> Hello,
> 
> On 2019-09-17 13:18, Christoph Pleger wrote:
> 
> > I want to use openvt from the kbd project to open a new virtual
> > terminal and start a wayland session there. But after entering 'openvt
> > -s -w -- dbus-run-session startplasmacompositor' on tty1, the KDE
> > Wayland session did not start on a new virtual terminal, but on tty1.
> > So, I tried to start a shell session first with 'openvt -s -w --
> > /bin/bash' and then, on the new virtual terminal, start the Wayland
> > session with 'dbus-run-session startplasmacompositor'. Though the
> > first of these commands successfully opened a shell session on a new
> > virtual terminal, the second command caused a switch back to tty1 and
> > again, the KDE session opened there, and the new VT was only used for
> > textual stdout/stderr.
> > 
> > So, my question is how to give all control for the new process to the
> > new virtual terminal and let the process started on the new VT
> > completely forget about the virtual terminal on which its parent
> > process was started.

I'm using X, and in xorg there have been hacks in xinit to use
different ttys.  Long ago, tty7 was used for X, but with the move to
systemd using logind there were apparently reports that authentication
failed in rootless xorg.  These days, using the same tty (at least
from startx) works.

I know nothing about wayland, nor about using openvt, but maybe
there is something in wayland or plasma which decides where to open.
> 
> This is totally crazy: Even when I omit the -w option to openvt, so that I
> can log out from tty1, then switch to the new VT and enter 'dbus-run-session
> startplasmacompositor' there, the KDE session starts on tty1, though of
> course logging out from /dev/tty1 changed its owner to root. So, how can a
> process with real UID, effective UID and saved UID (I checked that) change
> the ownership of a device that was owned by root?
> 

The perms are what logind is supposed to do: you login on a tty (if
the machine is multiseat, only one seat can do that) and you get the
permissions through dbus.

If not using systemd, elogind is intended to provide the same
authorisation (I say intended because I can't get it to work in my
own builds of current BLFS although it apparently works for other
people).

ĸen
-- 
thread 'main' panicked at 'giraffe',
/tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13