openat(AT_FDCWD, "/dev/tty7", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied) (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)Īll /dev/tty* device nodes belong to the tty group so what device is vt7 connected to? I just can't figure out what permissions I'm lacking to start X remotely without suid.Ĭurrently my user is a member of the groups video, audio and tty but using "startx - &" over ssh results in the following error: I think I have a fairly good understanding of this. Without using logind provider, and with kernel 5.8, adding user to input group should be enough to run X as user, but this also expose *all* input devices to user bashrc in a way, that autologin on specified TTY will never drop to interactive shell When trying to start X remotely, the only way to get this done is to enable autologin (for example via /etc/inittab for OpenRC), to get the seat. Use logind provider to get a seat, then use said seat to start X with all the needed accesses Where most secure here means a way that exposes least access. So, going from the most secure way to least secure way. The legacy suid way worked 'without any issue' simply because SUIDed Xorg binary would bypass any permission restriction out there, and since anyone could run it, everything was 'just working'. The logind provider allow locally seated user, which login on the vt (tty) to be given access over DRM (seems this has been lifted with 5.8 kernel) and access to input devices. I think there's general misunderstanding of what non-root X with logind provider does, and how it affects special usecases. For now I just worked around the problem by logging in the user automatically and autostart X. I was hoping to avoid it though.ĭoes using the hardware video card matter, or is this just for remote VNC? You could try running Xvfb for that instead and it probably wouldn't need elevated privs at all.Īnd I was always thinking that running vncserver :NN on the remote machine (where you just use some high number NN for your screen), automatically launches Xvfb ? And no remote video hardware is needed ?Īt least that is how I was always running VNC, except rare occasions when I needed to see what is on remote desktop screen, but it sounds that here it is not this use case. Yes, this is the last resort I have to fall back to unless there's no other way with elogind. I suspect some trickery is needed with loginctl but the man page isn't clear on this subject to me. Unfortunately I still get permission denied on the virtual console I choose, regardless of which one I try with that syntax. I run remote X all the time with "X :0 -query "
Maybe "xinit - vt1 &" would help? Try also "export DISPLAY=:0" before xinit.
Any hints on how to accomplish this would be greatly appreciated. (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)Ĭhanging the owner on /dev/tty0 moves the error to "virtual console 7" and changing owner on /dev/tty7 results in "no screens found" so I seem to be stuck on making elogind believe I'm actually logging in locally for this to work.
Logging in through ssh I'm missing the seat:Īnd startx of course errors out with lack of permissions on /dev/tty0: Logging in locally the seat info looks like this and startx works normally: Is there anyway around this other than to add suid to xorg-server again? The drawback is that I can no longer use the trick above.
Now, in the non root xorg era, elogind correctly identifies me as a remote user and refuses to give me the needed access rights to the remote machine's video card. Then I could start a vnc-server and access the remote machines's GUI. Posted: Thu 9:53 pm Post subject: Any way of starting X remotely in the non root xorg era?īefore the removal of suid on xorg-server I could always fire up X on a remote machine through ssh by typing: Gentoo Forums Forum Index Desktop Environments Gentoo Forums :: View topic - Any way of starting X remotely in the non root xorg era?Īny way of starting X remotely in the non root xorg era?