> It is completely possible to run X as a non-privileged user. The problem is that X handles all of the hardware abstraction, so it needs direct write access to hardware. For numerous reasons this is typically constrained to root.
This is no longer the case on a modern system with KMS/DRM graphics for many years, everything goes through the kernel. There are still some X drivers that directly control the I/O ports and PCI devices, but those hardware is nearly extinct today (the proprietary NVIDIA driver is the only major exception).
I've used a non-root X with Intel graphics for many years already, the desktop is fully functional. The problem, I think, is login managers. Some (many?) login managers must run as root, they need the privilege to log in as another user. To work around the problem, I decided to simply login to the command line via getty and startx by myself, works fine when I did this years ago. I'm not sure if login manager is still the problem today (update: ArchWiki says "GDM will run Xorg without root privileges by default when kernel mode setting is used.")
> You can imagine that the security concerns related to running X as root are significant. There is work to change this situation, such as the kernel mode select feature, but of course there is a substantial problem of inertia: [...]
To be fair, the author did mention the fact in the next paragraph.
Yeah, user-mode X11 was being implemented around 2014 or so. I was there at Red Hat when it was happening.
GDM itself doesn't need root anymore -- it can run as its own user. The way it's architected, there's what's known as a "greeter session". This is what provides the user picker, it has to be a full desktop session to provide accessibility / screen reader / OSK / all the bells and whistles, and it runs as the gdm user. Once you pick a user to start the authentication flow, it forks off a special helper that's marked setuid root so it can interact with PAM (unfortunately, arbitrary PAM modules can assume things about root credentials).
It also has the job of monitoring everyone's X servers and kicking you back to the greeter if the X server crashes for any reason.
One tiny thing here -- the article implies that the root X11 server launches GDM, but it's actually the other way. The DM is the one in charge of launching X11 servers, and it always has been. You can see evidence of this in the old XDMCP spec which was the standard for how remote display manager connections should work.
Thanks for pointing out my error about the DM vs. X11 starting first, I was hesitant to even try to explain how that worked because I find it confusing and I just knew I would get something wrong. I will correct the article when I have a moment.
> Once you pick a user to start the authentication flow, it forks off a special helper that's marked setuid root so it can interact with PAM (unfortunately, arbitrary PAM modules can assume things about root credentials).
Does this mean we could remove the helper's setuid mark if we know the PAM modules we need don't assume things about root credentials? Would we even need the helper then?
Yeah, probably, but PAM modules have a habit of crashing and can load arbitrary libraries, so for such a big system component I would still keep it isolated. But if you think you can trust it...
I remember the days at university sitting in the X Terminal lab so you could connect to the "big iron" to get applications like Maple. Or to connect to the Sun boxes, or the DEC machines. All with the local terminal handling window management. For a sliver of time, when security was less of a concern, there were actually web sites that would fire up a client (local to them) that would appear on your X terminal.
Meta: if you’re finding the monospace hard to cope with, browsers’ reader modes will get rid of it. If you like tweaking sites’ CSS instead, kill the `body { font-family: monospace }` rule. I found this to vastly improve the article’s readability. Seriously, site makers and theme designers, please stop using monospace everywhere as part of your aesthetic, as monospace fonts are really bad for extended prose.
Indeed. I only responded because I take issue with people who say things like
> "Seriously, site makers and theme designers, please stop using $PREFERENCE everywhere as part of your aesthetic, as $PREFERENCE are really bad for extended prose."
...as if it's a universal truth when in fact people have different reading capabilities. For example I'm dyslexic and I find it much easier to read monospace text than most dynamic width type faces because letters jumble up less for me. I'm not suggesting I'm the norm but it's certainly not as clear cut as many (like the GP) make out.
It doesn’t need to be universal, merely very significant: and it is. For the average person, monospaces significantly hamper reading and comprehension of extended prose.
As for dyslexics, I can’t really comment; the main study people cite is The Effect of Font Type on Screen Readability by People with Dyslexia (Rello and Baeza-Yates, 2016) <https://dl.acm.org/doi/10.1145/2897736>, but I don’t care to draw any conclusions from it because its range of fonts is surprisingly and stuntingly limited: in monospaces, it uses only the slab serif Courier (and a previous study it cites also only uses a slab serif for monospaces), whereas most monospaces used these days are sans-serif (I myself am an oddity, preferring and using Triplicate, one of very few true serif monospaces in existence); and I don’t like their choice of serifs either: CMU is known to be too thin because it’s not used as intended <https://news.ycombinator.com/item?id=27129620>, and Garamond is also known for excessive stroke weight variation (the thins being too thin, harming readability), though in both cases it’s not as great a problem on paper as on screen. But all up, I don’t think it’s fair to generalise from their data on the serif or the monospace properties, and that guts much of the paper.
I have a dyslexic sister but have never had occasion to query the (perceived) relative efficacy of monospace, and it’s a decade or more since I asked her about things like serif versus sans and I’ve forgotten what she said. I should ask her again.
> You cannot please all the people all the time when it comes to readability.
Someone should invent a technology where servers deliver semantic content and user agents control styling. Then you could, in fact, please all the people (except controlling designers.)
What `monospace` resolves to varies by platform and user configuration: you can change what it resolves them to.
As for browsers’ defaults, the transition away from Courier New on Windows (an objectively bad font, far too thin because they digitised it badly) is nearing completion; I think Firefox is the last one lagging behind (https://bugzilla.mozilla.org/show_bug.cgi?id=713680 is stalled for mediocre reasons). On macOS, all browsers have moved on to Menlo or better. My current recommendation is `font-family: Consolas, monospace` because Courier New is that bad, and once Firefox resolves that I’ll be recommending just leaving it at `monospace` (though there’s a pain point over the monospace font-size thing, with browsers tending to default to 13px instead of 16px and it’s all unnecessarily messy and I want browser makers to revert all of that because it’s a bad fit for the web now and causes far more trouble than it potentially solves).
True, but it can't be beaten for archiving (aka when I might want to keep some content for future reference when the blog is no longer up). It's is the only format that I trust to survive over the next 20 years without shifting its rendering.
The aside on DESQview really took me back. When I got my first PC in 1991, I was pointed towards DESQview for my needs, which was to be able to run multiple text-mode applications without the overhead of a fancy GUI (a not-unreasonable desire for a 25Mhz 386). When I finally gave in and started running Windows for some graphics programs, it ran in a DESQview window.
It always disappointed me that there were so few programs for the DESQview environment. I had a calculator app that would take up just enough space for a calculator and it was wonderful. IIRC, I also managed to set things up so that the emacs clone I used could be summoned in its own window via an emacsclient-style interface.
It's incorrect to say that programs can access the hardware directly using Mesa. Rather, they use Mesa which interprets their requests and grants or denies them.
For example if you try to read GPU memory that isn't yours you will get denied. Unless there is some bug or exploit.
Another interesting project is worth mentioning here: VirtualGL. VirtualGL allows you to run an OpenGL/3D application on a powerful remote graphics workstation, and to view it locally on a 2D-only diskless thin client, giving X's network transparency a significant boost.
In VirtualGL, all the 2D operations are still handled via X over the network. But doing the same for OpenGL is impractical for many reasons: the data is tremendous, and indirect rendering is not compatible with all applications.
VirtualGL uses a clever hack to solve the problem: 3D to raster conversion. On the remote 3D machine, 3D graphics is rendered using the graphics card and its driver as usual, but all the drawing operations are intercepted by VirtualGL via a LD_PRELOADed stub library, so VirtualGL knows about them. After the remote application has drawn something via OpenGL, VirtualGL immediately dumps the 3D framebuffer as a raster image, compresses it, and sends it over the network. Locally, the raster image is drawn at its intended location. The result is seamless 3D with native X experience (unlike a remote desktop).
This is no longer the case on a modern system with KMS/DRM graphics for many years, everything goes through the kernel. There are still some X drivers that directly control the I/O ports and PCI devices, but those hardware is nearly extinct today (the proprietary NVIDIA driver is the only major exception).
I've used a non-root X with Intel graphics for many years already, the desktop is fully functional. The problem, I think, is login managers. Some (many?) login managers must run as root, they need the privilege to log in as another user. To work around the problem, I decided to simply login to the command line via getty and startx by myself, works fine when I did this years ago. I'm not sure if login manager is still the problem today (update: ArchWiki says "GDM will run Xorg without root privileges by default when kernel mode setting is used.")
> You can imagine that the security concerns related to running X as root are significant. There is work to change this situation, such as the kernel mode select feature, but of course there is a substantial problem of inertia: [...]
To be fair, the author did mention the fact in the next paragraph.