Suggestions for X11 Libre

[rizalmart]

1. Make ABI compatible with Xorg as close as possible
2. Make X11 libre able to run on ordinary user, and make configuration both user and system-wide
3. Ditch X server drivers (xf86-input-* and xf86-video-*) and use KMS and MESA instead
4. Make autoconfigurable, override using config files when needed
5. Add permission-based security on input and screen sharing

[ToneyFoxxy]

1 - Why does this matter?
2 - Doesn't it already support this on SystemD? Making this possible without SystemD would be cool It's supported on both major login daemons. Should probably be default behavior though
3 - Wouldn't this break Nvidia compatibility or at least put it in the same boat as Wayland?
4 & 5 - Sounds dope

[smj-cc]

I'm running XLibre right now as my log in user. There is no systemd running (PID1 is s6).

Overriding configuration that I put in place will get your code expelled from my system permanently.

[ToneyFoxxy]

I'm running XLibre right now as my log in user. There is no systemd running (PID1 is s6).

Overriding configuration that I put in place will get your code expelled from my system permanently.

What is the output of ps -o uid,comm -A | grep X?

[smj-cc]

ps -o uid,comm -A | grep X?

smj$ ps -o uid,comm -A | grep X
1000 X

Edit: pstree -aclup (partial)

s6-svscan,1 -X3 -- /run/service 
  |-s6-supervise,527 mingetty.tty7 
  |    \`-xinit,533,smj /etc/xdg/xfce4/xinitrc -- vt7 
  |         |-X,5248 :0 vt7 
  |         |  |-xf86-video-inte,5250,root intel_backlight 
  |         |  |-{X},5249 
  |         |  \`-{X},5254 
  |         \`-xfce4-session,5255 

well.. that didn't format well... but you get the gist

[ToneyFoxxy]

smj$ ps -o uid,comm -A | grep X 1000 X

It seems it does support elogind, my bad. The prompt should say that when you install it. Also it would probably be good if this was the default behaviour

[nempk1]

2- Doesn't OpenBSD already runs xenocara without root? And its already possible on Linux with some problems since i remember reading about rootless X on Slackware package configure.

# Build rootless X packages. This is not the default in Slackware and is
# unlikely to be any time soon, as --enable-systemd-logind seems to really
# require systemd and does not function 100% with all graphics chipsets.
# In particular, resuming from suspend may not work with (at least) Radeon
# chipsets, and NVIDIA chipsets using proprietary drivers. Also, while
# rootless X works from "startx", it is unsupported by most login managers
# which will continue to start X as root.
#
# Feel free to try it out, though. To build rootless X packages, start the
# build like this:
#
# ROOTLESSX=YES ./x11.SlackBuild xserver xorg-server

https://harrier.slackbuilds.org/pub/slackware/slackware64-15.0/patches/source/xorg-server/configure/xorg-server

[smj-cc]

smj$ ps -o uid,comm -A | grep X 1000 X

It seems it does support elogind, my bad. The prompt should say that when you install it. Also it would probably be good if this was the default behaviour

There is also no elogind running here, no dbus, no udev, no pam.

Edit:

As the pstree shows, xinit was lanched from a mingetty login shell. (by a bash login script, if I log in on tty7)

[ToneyFoxxy]

There is also no elogind running here, no dbus, no udev, no pam.

That's cool and all but not really relevant

Edit: Why do you run your system this way? Is it just to avoid all RH stuff?

[smj-cc]

Edit: Why do you run your system this way? Is it just to avoid all RH stuff?

To retain control of my computer.

I'm not entirely apposed to running something like dbus, but then I'd have to vet all of it's code personally for security issues, each and every time it updates. Once it achieves the complexity of something like X, I'm not up to the task, so X does not run as root. I compromise in places, like the kernel, because I can't find any way around it.

Everything else does not run as root, unless It must to work, and it's work is important enough to warrant the risk, and small enough for me to audit the risk personally.

I've been running internet facing servers since 1994 ( 0.47 kernel ), and have not been broken into yet.

Edit:
I have a couple bridging firewalls one of which has no IP address. They automatically blacklist suspicious traffic on the fly via nftables rules for one week. They usually have 20K to 30K IP addresses in their blacklists. That's how many unique IP addresses attempt to break in within a week. And these are both on dynamic IP addresses.

[ToneyFoxxy]

To retain control of my computer.

I'm not entirely apposed to running something like dbus, but then I'd have to vet all of it's code personally for security issues, each and every time it updates. Once it achieves the complexity of something like X, I'm not up to the task, so X does not run as root. I compromise in places, like the kernel, because I can't find any way around it.

Everything else does not run as root, unless It must to work, and it's work is important enough to warrant the risk, and small enough for me to audit the risk personally.

I've been running internet facing servers since 1994 ( 0.47 kernel ), and have not been broken into yet.

Edit: I have a couple bridging firewalls one of which has no IP address. They automatically blacklist suspicious traffic on the fly via nftables rules for one week. They usually have 20K to 30K IP addresses in their blacklists. That's how many unique IP addresses attempt to break in within a week. And these are both on dynamic IP addresses.

That makes sense, but how do you know those connections aren't crawlers or people running an IP indexing script?

[smj-cc]

That makes sense, but how do you know those connections aren't crawlers or people running an IP indexing script?

Some of them are. Those that scan broad numbers of ports are not crawlers, and those running an IP indexing script are bad actors, and exactly what I'm trying to block.

But the vast majority make actual break-in attempts, such as using a login name of a known router default, or sending data structured to induce a stack smash, overflow, or binary data where ASCII was expected.

[rizalmart]

1 - Why does this matter?
2 - Doesn't it already support this on SystemD? Making this possible without SystemD would be cool It's supported on both major login daemons. Should probably be default behavior though
3 - Wouldn't this break Nvidia compatibility or at least put it in the same boat as Wayland?
4 & 5 - Sounds dope

1. To reduce recompiling, less package maintainer's burden. Also quick transition from Xorg to Xlibre

2. Xorg requires running on root and loads settings from /etc/X11.

3. Nvidia is the big bottleneck for this. Ditching X drivers focuses the development on X server and the development will be easier. Also easier deployment. No need for waiting X driver version on every new hardware release. MESA, Libinput, and the kernel will do.

4. Wayland compositors able to adapt hardware changes. Xlibre should do that. In Xorg it was hellish when you swap video card or monitor. The desktop does not work or just blank screen.

5. Security is one of the selling points of Wayland. Nowadays, security was very important especially when connected to the internet. In Xorg any app can be a keylogger, if linux desktop became even more popular. Xorg will be the primary target for entry point for snooping data. Microsofts Recall behaviour which captures screenshots in background on regular duration can be easily replicate on Xorg. Much better Xlibre utilize xdg desktop portals to make it secure.

[ToneyFoxxy]

1. To reduce recompiling, less package maintainer's burden. Also quick transition from Xorg to Xlibre

No it doesn't? XLibre is a hard fork and forks all necessary components of XLibre

2. Xorg requires running on root and loads settings from /etc/X11.

No it doesn't, as established by the conversation between smj-cc and I, root is not required at all for an X11 session. I think running it rootless causes a handful of bugs that should be ironed out, but that isn't really what you are talking about

3. Nvidia is the big bottleneck for this. Ditching X drivers focuses the development on X server and the development will be easier. Also easier deployment. No need for waiting X driver version on every new hardware release. MESA, Libinput, and the kernel will do.

No thanks, Nvidia support is a primary force for adoption of XLibre, why would this project kill that? Nobody is going to hold Linux hostage against Nvidia, Wayland has tried that for almost 10 years with 0 success.