[SOLVED] X server / X11 / Xorg / X not running rootless by default?

ExposeGlobalistsMadness · 2023-09-24 02:19:15

Devuan Chimaera was upgraded to Daedalus using standard bash instructions recently (on a Raspberry pi 400 arm64 architecture), and the X server was noted to not be running rootless despite this being a safer mode and a new feature of Daedalus/Debian Bookworm; as demonstrated by a test used in Debian:

$ ps -ef | grep X
root      2906  2905 10 Sep21 tty1     00:16:45 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.Sv2CPp0SVI vt1
myusername   17812 17235  0 00:45 pts/0    00:00:00 grep --color=auto X

Would the following implementation to run Xorg 'as user' indeed be appropriate, adding a line to /etc/X11/Xwrapper.config, as per an entry in the webpage cited above (using doas or sudo)? I couldn't find a relevant Debian wiki page.

$ doas rnano -w /etc/X11/Xwrapper.config 
# Adding following line to ensure that Xorg runs as user
needs_root_rights = no

Followed by a reboot. It appears to work for me.

Note that the display manager had previously been purged while in Chimaera to replace it with the system's interactive text login using an .xinitrc file (plus .bash_profile, .profile, and a soft link from .xsession to .xinitrc).

Is Daedalus/Bookworm not implementing this out-of-the-box because it could break some systems' setups, say, in case their GPU driver requires X server to run as root, or is there something missing?

soren · 2023-09-24 09:46:08

what is the output of below command, you should not need xorg wrapper.

ps -ef | grep seatd

ExposeGlobalistsMadness · 2023-09-24 12:48:11

Thank you.

$ ps -ef | grep seatd
myusername    3903  3899  0 08:18 pts/0    00:00:00 grep --color=auto seatd

I had been wondering about some seat messages; to update (again, changing my username to 'myusername':

seatd is not installed but libseat1 is, yet if I understand correctly, seat would be relevant in systems like mine whose display manager was removed, for interactions with the display.

$ apt list --installed | grep seat 

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libseat1/stable,now 0.7.0-6 arm64 [installed,automatic]

Notice seatd_libseat errors in Xorg.0.log, among other errors; note that some messages may relate to the use of a PS/2 converter cable and old keyboard and mouse PS/2 devices that hopefully use a lower amperage, for health reasons:

 $ cat Xorg.0.log  | grep "(EE)" -1
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    67.585] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 21 22:00:22 2023
--
[    71.899] (II) seatd_libseat try close /dev/input/mouse0 (-1:-1)
[    71.899] (EE) seatd_libseat device not open (/dev/input/mouse0)
[    71.901] (II) config/udev: Adding input device CHESEN PS2 to USB Converter System Control (/dev/input/event2)
--
[    72.048] (II) seatd_libseat try open /dev/input/event7
[    72.050] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[    72.050] (EE) seatd_libseat open /dev/input/event7 (-1) failed: -11
[    72.050] (**) vc4: always reports core events
--
[    72.052] (II) seatd_libseat try open /dev/input/event8
[    72.053] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[    72.053] (EE) seatd_libseat open /dev/input/event8 (-1) failed: -11
[    72.054] (**) vc4: always reports core events
--
[    75.916] (II) modeset(0): Disabling kernel dirty updates, not required.
[   853.977] (EE) event1  - CHESEN PS2 to USB Converter Mouse: client bug: event processing lagging behind by 21ms, your system is too slow
[  1362.632] (EE) event0  - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 36ms, your system is too slow
[  1518.837] (EE) event0  - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 25ms, your system is too slow
[...]
[  9311.158] (EE) event0  - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 33ms, your system is too slow
[ 10544.041] (II) event1  - CHESEN PS2 to USB Converter Mouse: device removed
--
[ 10544.305] (II) seatd_libseat try close /dev/input/event8 (40:40)
[ 10544.339] (EE) [libseat/backend/logind.c:199] Could not close device: Interrupted system call
[ 10544.339] (EE) seatd_libseat close failed 0
[ 10544.356] (II) UnloadModule: "libinput"
[ 10544.356] (II) seatd_libseat try close /dev/input/event7 (39:39)
[...]
[ 10544.749] (II) seatd_libseat try close /dev/input/event4 (30:30)
[ 10544.753] (EE) [libseat/backend/logind.c:199] Could not close device: Interrupted system call
[ 10544.753] (EE) seatd_libseat close failed 0
[ 10544.894] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
--
[ 10544.894] (II) seatd_libseat finish
[ 10544.898] (EE) [libseat/backend/logind.c:365] Could not release control of session: Interrupted system call
[ 10544.898] (II) Server terminated successfully (0). Closing log file.

Note also interesting security concerns expressed elsewhere about whether the user should be in the 'video' or 'seat' groups (in Gentoo anyway): https://forums.gentoo.org/viewtopic-p-8790141.html . I am not in the seat group:

$ id
uid=1000(myusername) gid=1000(myusername) groups=1000(myusername),5(tty),6(disk),20(dialout),27(sudo),29(audio),44(video),46(plugdev),102(netdev),104(input),106(render),109(bluetooth),110(i2c),1001(gpio),1002(spi)

So, if this type of installation does not need an xorg wrapper, how does one remove it?

Last edited by ExposeGlobalistsMadness (2023-09-24 12:55:51)

zapper · 2023-09-25 01:02:50

I don't know about most xorg as a whole, but xenocara might run rootless. I have no idea... I would have to look it up.

Problem is, xenocara's best features don't work as well on linux.

Pledge and Unveil for example do miles of good for openbsd, but I don't think anyone knows how to make those work in linux without monstrous changes.

ExposeGlobalistsMadness · 2023-09-25 08:32:15

Thanks a lot for your input, zapper! It spurred me to get a better grasp on the 'rootless' environment. Devuan's official release announcement for Daedalus stable sounds as it's about startx running 'rootless':

Rootless startx uses libseat1

A "devuan-announce" mailing, if I can summarize it adequately, elaborates about libseat1 controlling 'rootless startx', etc, and its ability to use seatd or elogind. There is the default 'autodiscovery' choice, or one can set the LIBSEAT_BACKEND environment variable. The user needs to be in the video group if using seatd as a backend and, "This is only relevant to running startx as a user, xorg run as root by a display manager is unaffected."

So the announcement is applicable, as I had purged my display manager. My .xinitrc hadn't been launching Xorg with startx:

[...]
# Launching dbus because it seems to help my browsers' videos not to stutter
# Adapted from https://daemonforums.org/showthread.php?t=5502
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then
	eval `dbus-launch --auto-syntax --exit-with-session`
fi

exec openbsd-cwm -c ~/.config/cwm/.cwmrc -d :0

So, to try startx:

Step 1 - With only one window manager (cwm) being used, and a website reporting the need for the path to the window manager to be specified with startx, the line was changed to:

exec startx /usr/bin/openbsd-cwm -c ~/.config/cwm/.cwmrc -d :0

(Other attempts, such as exec startx openbsd-cwm ... or startx openbsd-cwm ...I would bumped off X with 'Connection to the X server was lost'. A pointer for newcomers, in case it can help: Ctr+Alt+F5 or with most other Function keys except F1 might probably allow you to login and modify your system in an interactive shell without getting bumped out again, in case you ever get bumped off the X server).

Step 2 - Reset /etc/X11/Xwrapper.config without the added new line (mentioned above, "needs_root_rights = no"). This may be a pointless step, with the solution found later on.

Step 3 - Should LIBSEAT_BACKEND be set somewhere? echo $LIBSEAT_BACKEND returned a blank. The announcement satisfied my earlier query, explaining that libseat1 is useful for determining this backend. elogind (and five additional elogind packages) was already installed, perhaps out-of-the-box, while seatd was not (apt list --installed | grep seatd). I don't know whether 'autodiscovery' decided to choose elogind, as seatd was not installed at first, but the connection to X server was still lost on each reboot at this point. Even setting LIBSEAT_BACKEND=elogind or =logind or =seatd in /etc/environment didn't help in successive sessions. Note: from my notes, apparently LIBSEAT_BACKEND=logind appeared originally in that file, but some time ago I thought to comment it out, if memory serves me right, as logind maybe was not installed, and my system posed other challenges.

I then tried installing seatd in case it was relevant to resolving the lost X server connection, although that eventually got solved, as detailed above.

Step 4 - Checked whether the elogind service might run automatically:

$ doas service elogind status
elogind is running.

Step 5 - My user had already been checked to be in the video group (demonstrated above), so seatd should work for a rootless startx if seatd was chosen as the backend, if the announcement above was interpreted correctly.

Step 6 - Reboot.

Yet Xorg would still run as root (the serverauth file names are modified here in case that this is sensitive info):

$ ps -ef | grep X
root      2861  2860 14 00:53 tty1     00:00:07 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.Ss2Hejt3Av vt1
root      2985  2983  2 00:53 tty1     00:00:00 /usr/lib/xorg/Xorg -nolisten tcp :1 vt1 -keeptty -auth /tmp/serverauth.OJ9BbzLd8m vt1
myusername    3622  3618  0 00:54 pts/0    00:00:00 grep --color=auto X

With no success so far, next, gratefully, was to attempt soren's solution. He was bang on the money, thank you very much! Xwrapper did get in the way of startx running 'as user' until it was purged!

soren wrote:

what is the output of below command, you should not need xorg wrapper.
ps -ef | grep seatd

Note from my earlier reply, before installing seatd, that the output was blank (except for picking up my grep query). Next, with seatd installed:

$ ps -ef | grep seatd
root      2033     1  0 01:13 ?        00:00:00 /usr/sbin/seatd -g video
myusername    3875  3621  0 01:25 pts/0    00:00:00 grep --color=auto seatd

The Xwrapper package was suspected to be xserver-xorg-legacy:

$ provides Xwrapper.conf

dpgk -S filename works for installed packages only.  Otherwise, use  apt-file but need to do
sudo apt-file update   first and then apt-file search filename

xserver-xorg-legacy: /usr/share/man/man5/Xwrapper.config.5.gz

It didn't pull away any other packages when purging it:

$ doas apt purge xserver-xorg-legacy && doas apt autoremove 

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  xserver-xorg-legacy
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 234 kB disk space will be freed.
Do you want to continue? [Y/n]

With xserver-xorg-legacy gone; seatd installed; (elogind and seatd services both running, in case that is relevant); and with any LIBSEAT_BACKEND environment setting commented out in /etc/environment, Xorg would run 'rootless' without a display manager!

elogind had best stay: purging it would have meant removing 252 packages on my system, including calligra, network-manager, okular and udisks2.

So, maybe the apt dist upgrade procedure didn't remove the Xwrapper for those who needed it for some good reason. A mystery remains as to why the connection to the X server would repeatedly be lost when setting LIBSEAT_BACKEND=logind or =elogind or =seatd in /etc/environment, except when that line was commented out. Maybe /etc/environment isn't understood correctly as the meant place for the LIBSEAT_BACKEND setting? According to one post: "You can see the programs using /etc/environment with grep -l pam_env /etc/pam.d/* "

In my installation:

$ grep -l pam_env /etc/pam.d/*
/etc/pam.d/cron
/etc/pam.d/login
/etc/pam.d/sshd
/etc/pam.d/su

Or perhaps login in /etc/pam.d/ is related to libseat1?

Anyway, thanks a lot for your help, participants!

Last edited by ExposeGlobalistsMadness (2023-09-27 01:04:16)

zapper · 2023-09-26 00:00:49

Well if xorg can be used rootless, than xenocara damn well must be able to even more so.

Perhaps, display managers are even less of a problem for xenocara.

ExposeGlobalistsMadness · 2023-09-28 03:20:17

Thanks Zapper!

As an update, I got concerned about removing any Xwrapper recently. The 'tldr' version is:

- Could it be wiser to keep xserver-xorg-legacy because parts of my system were not responding?
- Perhaps check that /etc/X11/Xwrapper.config states allowed_users=console and add needs_root_rights=auto ?
- Maybe better run dpkg-reconfigure xserver-xorg-legacy (with doas or sudo) afterwards and select the "Console users only" default because that reconfigure command points out, "A good compromise is to permit the X server to be started only by users logged in to one of the virtual consoles."
- Despite the system recommending for the console user to run X, on my Raspberry Pi 400 system, root ends up running Xorg and the console user/user runs xinit. I'll leave it "as is" unless someone can improve on this.

The long story: I noticed cwm acting up; my key bindings for some applications didn't respond, etc, and I found an old Ubuntu Trusty man page (End of Life: "April 2024") for Xwrapper.config advising:

[...]
/etc/X11/Xwrapper.config contains a set of flags that determine some of the behavior of
Debian's X server wrapper, which is installed on the system as /usr/bin/X. The purpose of
the wrapper, and of this configuration file, is twofold.
Firstly, it is intended to implement sound security practices. Since the X server
requires superuser privileges, it may be unwise to permit just any user on the system to
execute it. Even if the X server is not exploitable in the sense of permitting ordinary
users to gain elevated privileges, a poorly-written or insufficiently-tested hardware
driver for the X server may cause bus lockups and freeze the system, an unpleasant
experience for anyone using it at the time.
Secondly, a wrapper is a convenient place to set up an execution environment for the X
server distinct from the configurable parameters of the X server itself.
Xwrapper.config may be edited by hand, but it is typically configured via debconf(7), the
Debian configuration tool. The X server wrapper is part of the x11-common Debian package;
therefore, the parameters of Xwrapper.config may be changed with the command
dpkg-reconfigure x11-common.
[...]"

So that got me concerned that maybe an Xwrapper or an Xwrapper.conf file should be kept. Reconfiguring x11-common also sounded relevant: (a) xserver-xorg-legacy had been purged; and (b) that man page goes on to point out that the file could set allowed_users to be rootonly, console, or anybody.

$ doas dpkg-reconfigure x11-common
Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.

Seeing how X socket directories were set, or perhaps reset, could reconfiguring x11-common be an important step to take if one were to amend Xwrapper.config or purge xserver-xorg-legacy?

I hadn't checked originally whether /etc/X11/Xwrapper.config was removed after purging xserver-xorg-legacy. At any rate, yesterday I tried re-installing --and then purging-- the package again, running doas dpkg-reconfigure x11-common after each of those operations. Unfortunately, I had only noticed that Xwrapper.conf was there after each dpkg-reconfigure operation, so I can't determine from those operations whether (a) each dpkg-reconfigure operation generated an Xwrapper.config; or (b) whether Xwrapper.config remained throughout, despite the provides command reporting that it was related to xserver-xorg-legacy (see above). In both instances, there was the same relevant last line:

$ cat /etc/X11/Xwrapper.config 
# Xwrapper.config (Debian X Window System server wrapper configuration file)
#
# This file was generated by the post-installation script of the
# xserver-xorg-legacy package using values from the debconf database.
#
# See the Xwrapper.config(5) manual page for more information.
#
# This file is automatically updated on upgrades of the xserver-xorg-legacy
# package *only* if it has not been modified since the last upgrade of that
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command as root:
#   dpkg-reconfigure xserver-xorg-legacy
allowed_users=console

That console setting sounded ok. Debian Bookworm's man page for Xwrapper.config explained:

[...]
allowed_users = rootonly|console|anybody
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.
needs_root_rights = yes|no|auto
Configure if the wrapper should drop its elevated (root) rights before starting the X server. Use yes to force execution as root, no to force execution with all suid rights dropped, and auto to let the wrapper auto-detect. The default is auto.
When auto-detecting the wrapper will drop rights if kms graphics are available and not drop them if no kms graphics are detected. If a system has multiple graphics cards and some are not kms capable auto-detection may fail, in this case manual configuration should be used.
[...]

If dpkg-reconfigure placed that "allowed_users=console" setting, perhaps it worked out that that default "console" setting was suitable; that session was not launched "as root" --remember that a display manager is not installed--, but from .xinitrc's exec startx command "as user" (or "as console"?) with success running rootless, as described above when purging xserver-xorg-legacy, but as pointed out now, with concerning artefacts. On the other hand, why isn't there the line needs_root_rights=auto which is the "default" setting according to that man quote?

Whatever the case may be, if one makes a change to Xwrapper.conf e.g. to set allowed_users=console, the man page then advises running dpkg-reconfigure as root afterwards, to keep it updated.

There was no mention found of xserver-xorg-legacy in Debian's forums to date, but its Debian Bookworm package page sheds some light:

[...]
setuid root Xorg server wrapper
This package provides a wrapper for the Xorg X server, which is necessary for legacy drivers and non-Linux kernels.
[...]

From the sounds of it, on the one hand maybe the package wouldn't be relevant for installations such as mine: a Raspberry Pi 400 doesn't sound 'legacy' (and doesn't Devuan run a Linux kernel anyway?), plus I am not using a display manager. On the other hand, I am inclined to keep xserver-xorg-legacy after the alarming change of behaviour with the lack of any observable cwm key binding response and other artefacts. Might someone have commandeered those bindings remotely without the package or, perhaps more on point, without me having run dpkg-reconfigure originally?

Having reinstated xserver-xorg-legacy and afterwards run doas dpkg-reconfigure xserver-xorg-legacy, note two different developments:-

(1) After disabling .xinitrc, and having recently started using an .xserverrc file that ends with
exec /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR , somehow, upon logging into tty1, an xfce session runs (I had launched some earlier sessions from a different tty using startxfce4 before powering off earlier, in case that is relevant, because I was concerned whether my .cwmrc configuration file had been infected at that point):

$ ps -ef | grep X
myusername    2865  2836  0 18:34 tty1     00:00:00 xinit /etc/X11/xinit/xinitrc -- /home/devuan/.xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.gTdAFhFLt4
root      2866  2865 16 18:34 tty1     00:00:10 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.gTdAFhFLt4 vt1
myusername    3067  3053  2 18:34 tty1     00:00:01 /usr/lib/aarch64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/aarch64-linux-gnu/xfce4/panel/plugins/libnotification-plugin.so 10 18874381 notification-plugin Notification Plugin Notification plugin for the Xfce panel
myusername    3869  3634  0 18:35 pts/0    00:00:00 grep --color=auto X

- Root appears to run /usr/lib/xorg/Xorg
- myusername is now involved with xinit, and wrapper-2.0 or libnotification-plugin !
- /etc/X11/Xwrapper.config had one setting:
allowed_users=console

Why is root taking over when "allowed_users=console"? So I thought to explicitly state the default needs_root_rights=auto declaration at the end of /etc/X11/Xwrapper.config in case the system needed to do a needs_root_rights check.

This was followed by the reconfigure command above. Surprise! the reconfigure command then launches an ncurses dialog box for the first time:

Because the X server runs with superuser privileges, it may be unwise to permit any user to start it, for security reasons.  On the other hand, it is even more unwise to run general-purpose X client programs as root, which is what may happen if only root is permitted to start the X server.  A good compromise is to permit the X server to be started only by users logged in to one of the virtual consoles.                                                                                                                                                                                                                         
Users allowed to start the X server:
                                        Root Only
                                        Console Users Only
                                        Anybody  

					< OK >

Console Users Only is highlighted in red as the recommended choice. By clicking "OK", it returns the following output:

$ doas  dpkg-reconfigure xserver-xorg-legacy
setting xserver-xorg-legacy/xwrapper/allowed_users from configuration file

...and the line order in /etc/X11/Xwrapper.config was somehow rejigged:-

needs_root_rights=auto
allowed_users=console

(2) Next, having by now run clamscan with no infection found, though not having gone through all folders yet; plus having cwm regenerate a new .cwmrc (which I soon enhanced); and now launching from tty1 having reinstated .xinitrc with its usual line (exec startx /usr/bin/openbsd-cwm -c ~/.config/cwm/.cwmrc -d :0):

$ ps -ef | grep X
root      2845  2844  8 19:39 tty1     00:00:46 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.f4FDEnqlKD vt1
myusername    2987  2855  0 19:39 tty1     00:00:00 xinit /usr/bin/openbsd-cwm -c /home/devuan/.config/cwm/.cwmrc -d :0 -- /home/devuan/.xserverrc :1 vt1 -keeptty -auth /tmp/serverauth.bBS5DQGfXN
root      2990  2987  0 19:39 tty1     00:00:03 /usr/lib/xorg/Xorg -nolisten tcp :1 vt1 -keeptty -auth /tmp/serverauth.bBS5DQGfXN vt1
myusername    3856  3678  0 19:48 pts/0    00:00:00 grep --color=auto X

So with my preferred setup (running cwm), the system decides for root to run Xorg, and for the console user/user to run xinit. I'll leave that setup unless someone can improve on this. The 'tldr' version at the beginning summarises this. Thank you.

soren · 2023-09-28 11:34:41

I think you need to back up a bit.

- Could it be wiser to keep xserver-xorg-legacy because parts of my system were not responding?

What parts?

The long story: I noticed cwm acting up; my key bindings for some applications didn't respond, etc,

What keybinds are not responding and what does your .cwmrc look like?

Ive used cwm in the past, ill will try and help you as i have system running now that does not involve the use of xorg-server-legacy and i use dwm as window manager and all my keybinds are working and i login using startx.

Last edited by soren (2023-09-28 11:39:01)

The officially official Devuan Forum!

#1 2023-09-24 02:19:15

[SOLVED] X server / X11 / Xorg / X not running rootless by default?

#2 2023-09-24 09:46:08

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

#3 2023-09-24 12:48:11

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

#4 2023-09-25 01:02:50

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

#5 2023-09-25 08:32:15

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

#6 2023-09-26 00:00:49

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

#7 2023-09-28 03:20:17

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

#8 2023-09-28 11:34:41

Re: [SOLVED] X server / X11 / Xorg / X not running rootless by default?

Board footer