Moblin Will Run X Server As Logged-In User, Not Root

nerdyH writes "An architect of the Moblin Project has announced that Moblin 2.0 for netbooks and nettops is the first Linux distribution to run the X server as the logged-in user, rather than SUID'd to root. The fix to this decades-old security liability comes thanks to 'NRX' (No-root X) technology reportedly developed by Intel, Red Hat, and others in the X community, and the Moblin-sponsored 'Secure X' project. Besides making Linux netbooks a lot more snoop-proof, it seems like this could lead to an X-hosting renaissance of sorts, since you wouldn't be risking the whole system just to open up a specific user's account to remote X servers."

Comments

frost nixon

[Anonymous Coward]

frost nixon

Re:frost nixon

[Philip K Dickhead]

Xroaches just lost a lot of value.

Re:frost nixon

[msuarezalvarez]

It doesn't?

Re:frost nixon

[Zero__Kelvin]

No, it doesn't. It runs most everything as the "Administrator" user, which is a lot like a root account, but without even the level of security that logging into Linux/Unix as root provides ;-)

Re:frost nixon

[mehemiah]

um, the end of the name of that picture (scrot.png) made it look really suspicious. for the rest who looked at the url of that link before clicking, its of a screenshot taken by the scrot cli screenshot program not a pict of some scrotum. FYI

Re:frost nixon

[Anonymous Coward]

Windows in fact runs (almost) nothing at all as "Administrator". Please find a Windows machine and run Task Manager. There are multiple OS accounts used, like like SYSTEM, LOCAL SERVICE and NETWORK SERVICE, so unlike root on Unix these are shielded from each other and from parts of the system they have no business dealing in. And furthyermore, important parts of the windowing system are implemented as DLLs (shared libraries). Those are run in your process space, and thus under your user account.

Re:frost nixon

[Anonymous Coward]

There are multiple OS accounts used, like like SYSTEM

Yeah, that doesn't sound at all privileged.

LOCAL SERVICE and NETWORK SERVICE, so unlike root on Unix these are shielded from each other and from parts of the system they have no business dealing in.

On Unix, each service/daemon/whatever you want to call them typically has its own account.

IMHO

[rodgster]

This is something that is long overdue.

Re:IMHO

[digitalunity]

Ya think? X is older than I am.

Can someone spare me reading the article and let me know if DRI is still possible without root?

Re:IMHO

[jmorris42]

> Can someone spare me reading the article and let me know if DRI is still possible without root?

Yup, this whole thing rests on the new kernel modesetting. That was the last thing that required root to be able to directly frob bits on the video card. DRI also goes into the kernel as it should. The kernel is supposed to own all of the hardware and expose safe APIs for user apps to access it. For historical reasons video has been the exception to that rule. No longer.

Re:IMHO

[Enleth]

Er, the same way USB was for years? Actually, DRI, too. The driver exposes a pseudo-device in /dev/, which actually is a socket-like, high-throughput mmap wrapper and the X server opens it. Given appropriate file permissions and group membership, this can be done from a user account.

Re:IMHO

[afidel]

Sounds like Windows NT 3.5, wonder if it will get moved back into kernel space for performance reasons just like NT4 moved video back into kernel space.

Re:IMHO

[sofar]

Yes, DRI access is done through /dev/dri* and works correctly.

Re:IMHO

[jmorris42]

> Sounds like Windows NT 3.5, wonder if it will get moved back into kernel
> space for performance reasons just like NT4 moved video back into kernel space.

Not the same thing. The video hardware belongs in the kernel in exactly the same way as sound, mass storage and the keyboard/mouse do. *NIX and Windows are now alike in that and it is good.

What Windows did was bring most of the next layer up the chain into kernel space. This would be more like putting the whole X server and bits of GTK and/or Qt into the kernel, not just running it as root. Yes it improved performance some, but the security implications are horrific.

Re:IMHO

[TheRaven64]

Yes, it's one of the things that happens when you elect an OpenBSD developer (Matthieu Herrb, who prototyped this two years ago) to the X.org steering committee. Thank $DEITY it's not just Linux developers working on X.org.

Re:IMHO

[Anonymous Coward]

Ya think? X is older than I am.

Wow, how young are you? X is only in it's early 20's.

Re:IMHO

[Anonymous Coward]

get over yourself

Re:IMHO

[Bandman]

Excellent. Something else for my old coworker to screw up when he tries to rsync / to another machine.

This time it should make for excellent visual fireworks as opposed to just going crazy like last time.

Re:IMHO

[multi io]

Sounds like Windows NT 3.5, wonder if it will get moved back into kernel space for performance reasons just like NT4 moved video back into kernel space.

No, NT4 moved hardware-independent stuff like the GDI and the window system into kernel space, where it doesn't really belong. The hardware-specific video card drivers were always in kernel space, where they do belong.

In X, hardware-independent stuff like window managers and widget sets ran in user space, where they do belong, while the hardware-specific video card drivers also ran in user space, where they don't really belong.

Pick your poison.

Re:IMHO

[Anonymous Coward]

X is 25 this year. It's also older than me (22).

Re:IMHO

[Eravnrekaree]

AFAIK the modesetting is minimalist to restore the console after X has crashed and so on, not a full blown graphics system. You are also wrong about putting things in the kernel. Putting something in the kernel does not automatically make it responsible or safe, but in fact, it can mean the opposite, making code even more destructive. It is true that applications should not contain driver code, but drivers can exist outside of the kernel, and applications, and provide a safe API to applications. Being in the kernel does not make code safer, being well written and well designed does, and its also possible to make well designed userspace code, and the system is even more protected from userspace code.

Re:IMHO

[Eravnrekaree]

I strongly disagree that video hardware is better in the kernel. In fact, it actually can make the system much more unstable. Adding code to the kernel can actually expose the system even more severely to bugs in that code. Adding code to the kernel does not make the code safer but actually more dangerous. Drivers can also exist in userspace and there are definite benefits of this, including the system is better protected from code in the drivers. The only benefit from having a driver in the kernel is it may improve performance a little, but that is debatable i am sure. There are big downsides, in that it would further fragment the video driver community. With video drivers in userspace and connected to X as they have been, it has not been necessary to maintain a seperate set of drivers for each OS. This has allowed FreeBSD and Linux to benefit from using the same base of drivers. Putting drivers into the kernel would likely mean the drivers would use some OS specific kernel interface and would need major porting to be used on other OS.

Re:IMHO

[Foolhardy]

Actually, there are two parts to a video driver on Windows NT, in all versions up to 5.2. In the "Windows 2000 Display Model" (the same one used in NT4), the vendor supplies a display driver, and a miniport driver.

The miniport handles things like resource allocation, memory mapping, handle interrupts, etc. This has always been in kernel mode, because it has to talk to the hardware.

The display driver is for high level drawing and rendering commands. It provides accelerated interfaces for GDI, DirectDraw and Direct3d. This, along with the Win32 windowing and graphics servers (left side of original diagram), used to live in user mode int NT3.x inside of csrss.exe with winsrv.dll. CSR still contains many functions that were never moved into kernel mode in win32k.sys.

Performance was one reason to move the display driver and winsrv into kernel mode, but I guess the biggest reason was to simplify the interface between the Win32 server and user mode clients by eliminating all the IPC marshaling. Win32k can now just reach into the client process's memory, same pointers and everything, instead of packing things into shared memory or an LPC messages.

Vista's new display model is more complex, but for the most part has a user mode display driver again.

Re:IMHO

[Rich0]

Sure, I'm fine with putting video drivers in userspace (think microkernel), but it needs to be done in a more generic fashion. Those video drivers should be accessible by ANY application - they shouldn't be X11-specific. Those drivers should also allow for windowed hardware access by individual applications (application asks server for a window, then can do direct hardware access within that window). The driver should of course enforce rights to space on-screen so that it is not possible for a program to draw outside its window.

IMO the screen should just be like any other piece of hardware on the system - it should be abstracted by drivers and designed to work in a multi-application/user enviornment.

Also - better kernel support for video cards would actually improve stability. Right now if my X server crashes chaces are that I'm not going to be able to switch to a virtual text console, since the kernel doesn't know how to re-initialize my display.

One of the shortcommings in security

[santax]

Just got fixed by this. To be honest, I don't know how they've done it, but I know this is a good thing. This will make X and linux more secure and I can only applaud that.

Re:One of the shortcommings in security

[Freetardo Jones]

I don't know how they've done it, but I know this is a good thing.

They've done it by removing the responsibility of X talking directly to the graphics hardware by implementing Kernel Mode Switching for graphics drivers (among other much needed overhauls to the Linux graphics stack). Thus X can now access what it needs at the logged-in users' level and doesn't need root.

Re:One of the shortcommings in security

[Timothy Brownawell]

Just got fixed by this. To be honest, I don't know how they've done it, but I know this is a good thing. This will make X and linux more secure and I can only applaud that.

I think what is basically boils down to, is that instead of X talking to the hardware directly it now talks to a file under /dev/ just like everything else.

Re:One of the shortcommings in security

[Hatta]

How big of a security problem was this? I haven't seen a linux system with open ports for X in 10 years. Anyone who wants to use remote X just uses ssh -X, it's easier to set up than xhost anyway.

Re:One of the shortcommings in security

[santax]

thanks to you and Freetardo Jones. This is language i can actually understand :)

Re:One of the shortcommings in security

[sofar]

Every X API allowed the user to insert possibly bad data into the Xserver, possibly exploiting the suid root bit by forcing a buffer overflow/underrun etc.

Imagine how many X API's there are, and all of them result with user data ending up in root memory space. Local root exploits could be anywhere in any X library.

Re:One of the shortcommings in security

[dgatwood]

Huge. XFree86, for example, is over 2 million lines of code. Given that there is an average of one security bug per 1,000 lines of code (according to the DoD), this means that there are likely over 2,000 security bugs in the X server. That's 2,000 privilege escalation attack vectors that a local user could use to gain root privileges by smashing on the X server in the right way.... If the X server runs as the local user, then all of those bugs become mostly moot (crash risk notwithstanding).

Re:One of the shortcommings in security

[kelnos]

Well, if the flaw is in an X *library*, it doesn't matter, as only the clients (running as the regular user) use those. The X server doesn't need or use libX11, libXrandr, libXext, etc. at all.

But yes, true -- any exploitable flaw in the X server itself (or any of the extensions compiled into or loaded dynamically by the server) could result in root access.

Re:One of the shortcommings in security

[TheRaven64]

Not exactly. There is an average of one bug per 1,000 lines of new code. X.org has been in constant development since 1984. A lot of those 2,000 will have already been fixed. Note that X.org is part of the OpenBSD base system and so undergoes the same kind of rigourous code review. X.org, XFree86, and then X.org is probably the most reviewed and tested piece of software in widespread use.

Re:One of the shortcommings in security

[ls671]

Yep, that's it I guess, changes to hardware management. I have been running Xvnc X server for years as a normal user since it doesn't need to talk to the hardware.

Re:One of the shortcommings in security

[Hatta]

So the kind of attack I'm envisioning is say, I'm a malicious site operator and you ssh -X into my system. You start an X client program that I've hidden an exploit in. That X client exploits your X server giving me root on your machine.

It wouldn't work the other way would it? If I ssh into your machine and run an X client, I can't root your machine.

Re:One of the shortcommings in security

[MichaelSmith]

I don't know how they've done it, but I know this is a good thing.

They've done it by removing the responsibility of X talking directly to the graphics hardware by implementing Kernel Mode Switching for graphics drivers (among other much needed overhauls to the Linux graphics stack). Thus X can now access what it needs at the logged-in users' level and doesn't need root.

I could always do startx as a user. Was I missing out on some hardware features by doing that?

Re:One of the shortcommings in security

[pavon]

No, X-Windows was installed as SUID root. SUID is a file flag in the standard unix permision system that indicates that when anyone (who has permission) executes a file, the user ID for the process is set to that of the file owner, in this case root. So, basically you have been running the X server as root and you didn't know it.

Setting the SUID flag of root-owned files is strongly frowned upon. If you are doing this you are basically stating that you trust that application as much as you trust the kernel, because if there are any exploitable bugs in it, you've just given all your users complete root access. But for X there was no option till now because it handled it's own hardware access.

Re:One of the shortcommings in security

[maxwell demon]

If you are doing this you are basically stating that you trust that application as much as you trust the kernel, because if there are any exploitable bugs in it, you've just given all your users complete root access.

Actually, I think I've read somewhere that there's another barrier, so that even root cannot do everything the kernel can.
Of course if you enabled loadable modules it's easy to get into the kernel once you are root.

Re:One of the shortcommings in security

[kinnell]

Lets say you are running a web browser on X and you load a malicious web site which exploits a flaw in your browser which enables it to communicate with the X server. The X server has direct access to the video hardware, so if there is a flaw which an X client (your compromised web browser) can use to control your video card, you can do arbitrary DMA transfers outwith kernel control. This is quite a complicated vector but it does exist, and requires either the X server to be flawless or all X clients to be flawless. In effect you are offloading responsibility for your system security from the kernel to your X server.

Re:One of the shortcommings in security

[bluefoxlucid]

And OpenBSD fixed a privilege escallation bug in Xorg that had been around since the X11 code base of before-OpenBSD-was-born. They're no faster than the rest of us.

Re:One of the shortcommings in security

[efalk]

You are correct. Applications still run as the logged-in user. The only vulnerability is if there was some sort of security hole in the server, and we all know that could never, ever happen.

Re:One of the shortcommings in security

[Rich0]

It sounds like this isn't quite just like everything else - the kernel is at least providing some non-root access to hardware, but it isn't abstracting the hardware at all.

Suppose that in order to play a sound you couldn't just send wav data to /dev/dsp or whatever, but instead you had to open the device, send it a command to create a memory buffer, send data to the buffer (in the right format for your make/model sound interface), send a bunch of IO commands to the sound card (including port number and data details), and set up a pointer to your own interrupt handler that you pass to the device so that you can keep the buffer alive. Sure, it might work without root, but basically all you have is the kernel passing through raw device IO and not actually providing any kind of driver.

Confused article.

[Timothy Brownawell]

Linux's SUID X server problem has been kind of a "dirty little secret" for many years. Most modern distributions include a few crude workarounds, such as dimming the display and then freezing X whenever the user is asked to type in a root password. Getting rid of the SUID bit altogether ought to make netbooks powered by Moblin technology much more difficult to snoop on over the network.

This does not make sense. Graphical sudo wrappers have nothing to do with X being suid, and neither does anything to do with network traffic.

It seems likely that with NRX technology, you could run X apps over a network with much less risk to the app server (the system that runs the "X client" component, in the backwards terminology of X).

This is actually backwards, the only place there's less risk is for the system that the X server is running on.

Re:Confused article.

[Anonymous Coward]

Well he did correctly state

you could run X apps over a network with much less risk to the app server

and then quickly made himself look stupid again.

X Hosting?

[Microlith]

I'm not sure I grasp the concept of X Hosting, and how this non-SUID server would help that.

X is not required to be running on the remote system for X11 forwarding over SSH. Even running an Xvnc server doesn't require it to be SUID. This seems to be entirely a local security gain for users who will be interacting with local graphics hardware.

Re:X Hosting?

[John Hasler]

> I'm not sure I grasp the concept of X Hosting, and how this non-SUID server would help
> that.

It wouldn't. The author of the article hasn't the foggiest notion of how X works (well, he does have a foggy notion, but it's wrong). The machine(s) running the client(s) run only the client code and run it as the user.

Re:X Hosting?

[ls671]

> This seems to be entirely a local security gain for users who will be interacting with local graphics hardware.

correct !!!

Re:X Hosting?

[timeOday]

Besides, X, although designed explicitly from the beginning to host remote applications, sucks at it. It is unusable on a link with any significant latency, and cannot migrate a client to a new server. VNC and Remote Desktop, though seemingly less elegant solutions, work much better, mainly because they are synchronized more loosely.

Re:X Hosting?

[mi]

X, although designed explicitly from the beginning to host remote applications, sucks at it. It is unusable on a link with any significant latency

This is not entirely fair, because the networks, for which X was designed, did not have "significant" latency, even if bandwidth was not that great. In 1993, working for a Boston university, I would routinely log in to a friend's account in an LA school and run xclock on my X-terminal — right next to the one running on the server downstairs.

Both processes — one running two stories below and one thousands miles away — ran smoothly, the seconds-hands were moving at the same time, and it would've been easy to mistake one for the other, had it not been for the 3-hour difference between them...

As for migrating the client, X-protocol does not prevent the client from reconnecting to a different X-server, etc. Most just didn't implement it — probably, because of the load this would put on the application server... BTW, with Remote Desktop (and vnc) this tasks are also the responsibility of the client — it is just implemented now, because the need arose due to drastically different usage patterns...

VNC and Remote Desktop, though seemingly less elegant solutions, work much better, mainly because they are synchronized more loosely

That loose synchronization is the price, that X-windows designers did not want to pay. Time has shown, that it is a reasonable trade-off, but it was not obvious. And, again, the networks, that had such bad latency, weren't all that common.

Re:X Hosting?

[bluefoxlucid]

Both processes — one running two stories below and one thousands miles away — ran smoothly, the seconds-hands were moving at the same time, and it would've been easy to mistake one for the other, had it not been for the 3-hour difference between them...

Not that it matters, since you still have to go through the process of converting a complicated graphical representation system to Hour:Minute:Second, rather than just having a decoded display.

Re:X Hosting?

[Eravnrekaree]

Ive used X over network connections and I know this to be incorrect, at least over a ethernet. THere are also solutions avialable for the problems you mention, or which can be addressed. There are various products that will compress the X data stream so that it uses less bandwidth and can perform quite acceptably. Such as NX. There was for a while a provide called xmove which was an X proxy to which your X clients would connect, you can send xmove command to redirect the display of the X client between different X servers, allowing your X programs to be moved between X servers. The code is out of date but it would be a useful thing to have that sort of capability and would strengthen X as a remote desktop solution. X is actually a very successful and well performing system and is a very well designed graphics system that actually exceeds windows in capability.

Correct me if im wrong

[Anonymous Coward]

But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....

Re:Correct me if im wrong

[metamatic]

The X server is the program on the local machine that displays the pixels.

The program you run on some other system via the net is the client, even if the thing it's running on is called a server.

The X server traditionally runs as root. You are likely unaware of this because it's started automatically as part of the init process.

The X server running as root is independent of whether the X client is running as root.

Re:Correct me if im wrong

[ls671]

> But running apps remotely and having them display on a local X server _NEVER_ required root access of any kind on the remote server....

entirely correct, the X server is the component talking to the video card.

Re:Correct me if im wrong

[Lennie]

"The X server traditionally runs as root. You are likely unaware of this because it's started automatically as part of the init process." On many systems it's started by init, but that's not the reason it has root, it has root because the X-binary has setuid bits set.

Re:Correct me if im wrong

[Alex Belits]

Actually on any modern desktop/workstation running X it's possible to remove setuid bit from X server, and everything will continue working because X server is started by display manager (usually gdm) running as root. Setuid /usr/bin/Xorg exists entirely for convenience of the users who log in at the console, then run xinit (all five of them).

Re:Correct me if im wrong

[Anonymous Coward]

What does that have to do with anything? The article is about not running the X server as root on the local machine. RTFA for enlighenment about why this is good, but for most people it is paranoid. However, sometimes paranoia pays--especially if it doesn't cost anything.

Though the article is wrong about this always being an issue. Before 3D accleration, X ran fine as a normal user. (I don't remember why, since rendering 3D is done by the DRI kernel driver) Some setups required X start as root then dropped priv, but I don't see how this makes a difference. In fact, the framebuffer kernel driver was made so programs (such as X) could access the video card without needing root privs.

Poor understanding of X

[Anonymous Coward]

The article repeats the common misunderstanding: "in the backwards terminology of X"

What exactly is backwards about this? X is the server, and the apps are clients.

Think about it: The client initiates the conversation with the server. The client tells the server what to do.

How is this backwards?

Re:Poor understanding of X

[Nutria]

How is this backwards?

It's only backwards in human thought, because people have the ingrained presupposition that the server is the Big Machine In Another Room, and the client is the Little Machine On Your Desk.

Re:Poor understanding of X

[stevied]

It's backwards to the vast majority of people who never used the network capabilities of X.

Sadly, even when you demonstrate it in these days of Terminal Services / Remote Desktop / VNC, people aren't impressed. The fact that it worked just as well 20 years ago (when it was in fact more use - you generally had a thinner, dumber X terminal, and a choice of minis / servers to do your computation on) passes them by ..

Re:Poor understanding of X

[Anonymous Coward]

There seems to be nothing wrong when you run your apps locally. But when you use remote applications the app server runs the X client and the client runs the X server. It is still technically correct, but that doesn't make it any less confusing for people new to this stuff.

Re:Poor understanding of X

[TheRaven64]

It's backwards because the client applications run on the server, and the server runs on the client machine.

Re:Poor understanding of X

[John Hasler]

Wrong. The server runs on the machine you are sitting in front of and provides display and input services to the clients programs, which may each be running on a different machine.

Re:Poor understanding of X

[glassware]

It's backwards from the perspective of a human being. If for some reason you are a little metal box stuck in a rack closet somewhere with no lights and powerful A/C, maybe you could make the argument that the remote faraway desktop might be a "server" and you're a "client". But in real language terms, you need to accept the fact that humanity has decided to call big boxes in server rooms "servers" and desktop computers on peoples' desktops "clients".

But no human being has ever thought that way, except when a bunch of guys throwing together the X protocol said "Oh, wow, man! You know, like, what? It's so cool! It's totally reversed! The client is the server and the server is the client! Why don't we force everyone who is already calling this big enterprise hardware device a server to also call it a client? Then we can force everyone who already calls their desktop computer a client to call them servers! Won't that be wild!"

Get over yourself. Once you start using language the way the rest of the world does, you will have a lot fewer snarky arguments that wind up with you feeling clever while the other person walks away shaking his or her head sadly.

Re:Poor understanding of X

[Anonymous Coward]

But no human being has ever thought that way, except when a bunch of guys throwing together the X protocol said "Oh, wow, man! You know, like, what? It's so cool! It's totally reversed! The client is the server and the server is the client! Why don't we force everyone who is already calling this big enterprise hardware device a server to also call it a client? Then we can force everyone who already calls their desktop computer a client to call them servers! Won't that be wild!"

Uh, no. Clients request services from servers; servers host services to clients.

That's what it has always meant, whether you mean a program or a box. The problem is not "using language the way the rest of the world does," the problem is people not understanding what they're talking about.

Re:Poor understanding of X

[Anonymous Coward]

All is clear if we understand what it is serving. X is serving the display to your eyes. Web-server is serving pages to your web-client/browser.

Re:Poor understanding of X

[Bandman]

People are just used to working on the client locally and connecting to a remote server. This is using a local server and a remote client. No big problem, unless you don't fully understand client/server relationships

Re:Poor understanding of X

[Bandman]

>The server runs on the machine you are sitting in front of

> the server runs on the client machine

I'm pretty sure you guys are saying the same thing...

Re:Poor understanding of X

[Timothy Brownawell]

All is clear if we understand what it is serving. X is serving the display to your eyes. Web-server is serving pages to your web-client/browser.

X is serving the display and keyboard (and your eyes) to your firefox and xterm.

Re:Poor understanding of X

[rdebath]

For the way that X works it's correct.

But, X is the wrong way around, you should have a client running on the local machine that connects to the remote machine and provides it with a remote display. Like telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows or "ssh -X"!

In fact X is that ONLY one that puts the server next to the display with the security implications inherent in that.

Re:Poor understanding of X

[Anonymous Coward]

But, X is the wrong way around, you should have a client running on the local machine that connects to the remote machine and provides it with a remote display.

"Provides it with a remote display" = "serving"

That's why X is a display server, get it? It's not the wrong way around!

Re:Poor understanding of X

[rdebath]

Yes I get it, the TCP/IP connection connects to the machine with the screen, so the machine with the screen is the server in X.

BUT, X is the wrong way round. NOTHING else connects a display with a process that way and even with X the first connection is FROM the display TO the CPU server and tell the CPU where to find the X server. So every remote X connection actually consists of two connects one from the DISPLAY TO the CPU (usually cached and often an XDM connection but it can be a telnet) the second is FROM the CPU TO the DISPLAY.

AND this leads to the ridiculous situation of the server machine having to logon to the client machine (with an MIT magic cookie) to send back the response to a command received through an already open connection!

This is really noticeable with "ssh -X" where the initial connection is the SSH connect but SSH has to provide an (insecure) open port for the connection BACK to the X server to send X over secure connection.

Re:Poor understanding of X

[maxwell demon]

The client applications run on the server?

At least in the setups I'm used to, no client program may be run on dedicated server machines (if that is what you mean with "server"). After all, you don't want e.g. to get all computers unusable because some program runs wild on the central file server. When running X client software remotely, it's on another "client" machine, that is, on another of those machines not restricted for a certain purpose. In many cases it's a machine which you could in principle go to and work direcly on it, but why bother if you can as well log in remotely.

Now the server is traditionally the side which manages the ressource, and the client is the side which uses the ressource. With a file server, the server is running on the computer with the files, and the clients are the programs running elsewhere. And with the X server, the server is running on the computer with the display (i.e. your computer), and the client may run elsewhere. Note that if your remote X program also accesses files from a file server, the client is again your program running on the remote computer (your local computer isn't involved at all in that case, unless it happens to be the file server).

Re:Poor understanding of X

[maxwell demon]

Ok, so every time you start a new GUI program, you have to immediatly tell your local display client that you have started a new display server, whose services you want to see? Doesn't sound like an environment I'd like to work in (although I admit it would be more secure).

To make an example how this would look like:

Step 1: You start a display server program (e.g. firefox).
Step 2: You ask your display client (the program managing the screen) to connect to the newly started display server (firefox). To do so, you would have to know how to connect to that program (e.g. firefox writes the port to use to stdout, and you tell your display manager to connect to this port).
Only then the window appears, and you can start interacting with firefox.

Re:Poor understanding of X

[jonadab]

> What exactly is backwards about this? X
> is the server, and the apps are clients.

It seems backwards because we usually think from a user's perspective.

The X terminology can be viewed as correct and forward, because the server is a system that provides services of some kind, and the client as the system where they are used. With X, the terminology is set up the way it us based on the understanding that the server provides services not to the user, but to applications: services like "show your UI to the user" and "get input from the user".

But we usually think not from the perspective of the application code, but from the perspective of the user, and so we usually think of a system that provides services to the *user* as the server, and the system where the user sits and uses them as the client. Viewed that way, the remote system that provides applications that do stuff would seem to be the server, and the system where the user uses the services would seem to be the client. That's how it works for an application server, for instance: the apps run on the server, but you use them on the client, with the client's keyboard, mouse, and monitor. A print server or file server is similar: the printer driver or filesystem runs on the server, and it's used from the client when the user prints something or saves a file or whatever. MS Terminal Server works this way also: the apps run on the server, and the user connects from the client (via rdp).

With most client-server things, then, the terminology is user centric. With X11, the terminology is application-centric.

So the reason X terminology feels backwards is because most people have an easier time identifying with the user than with the computer program that the user is using.

Re:Poor understanding of X

[jonadab]

> Why don't we force everyone who is already calling
> this big enterprise hardware device a server to
> also call it a client?

I don't think that was the thought process that went into it.

The problem is that the people working on X, including the people managing the project, were all programmers, and they were all thinking from the perspective of the code, rather than from the perspective of the user. So when they asked themselves which system is providing services, and what services are being provided, they came up with answers like: the system with the display hardware (something not all computers had back then) is providing a service, the service of displaying a window.

I agree that the X client/server terminology is backwards, from the perspective of the user. But they didn't do it deliberately to be weird, obtuse, or annoying. They just failed to stop and think about the end user who doesn't know or want to know anything about the internal design of the system.

Most of the people using X and the computers it ran on *were* programmers, so it's kind of understandable. End users with no programming experience back then were mostly using eight-bit microcomputers with no networking stack (think: DOS 3.0), so such users didn't enter into the thinking too much. It was another era. X is a bit of a dinosaur, one of the oldest client/server things still in widespread use.

Re:Poor understanding of X

[Anonymous Coward]

"[X11's use of client/server] is only backwards in human thought" - and that's why the dominant GUI is Microsoft Windows. The whole point of having a GUI is to adapt to humans - only humans need the graphical part, for instance.

Re:Poor understanding of X

[Lord Bitman]

Because in order for the Client-Server architecture to be useful, a user expects the X App to be a constantly-running server, to which a Display client can connect in order to view it. Display disconnections should be everyday events, not errors, and multiple display connections should be possible without ugly workarounds.

Think about it: The client (XApp) initiates the conversation with the server (Interface, including the Monitor, Mouse, and Keyboard). The server tells the client what to do, and the client sends replies (what to draw) back to the server. That's backwards.

Re:Poor understanding of X

[Anonymous Coward]

So every remote X connection actually consists of two connects one from the DISPLAY TO the CPU (usually cached and often an XDM connection but it can be a telnet) the second is FROM the CPU TO the DISPLAY.

True, but the connection from the display to the CPU is not a client/server connection.

Re:Poor understanding of X

[rdebath]

Ok, so every time you start a new GUI program, you have to immediatly tell your local display client ...

Of course not, none of the examples I gave above works like that

... telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows ...

they all send data down the same connection. Either through an already open file descriptor or a kernel mediated virtual device.

VNC is probably the closest simulation, you connect to the VNC server (on the server machine) and it gives data to show on your client display. The X clients connect to it through a unix domain socket (which is secured). Unfortunately, plain VNC has no encryption, nor does it use unix domain sockets to listen for X. :-(

Re:Poor understanding of X

[rdebath]

Yes it is.

Telnet server, listens for telnet connections.

XDM server, listening for the "X11 Display Manager Control Protocol".

Re:Poor understanding of X

[Anonymous Coward]

But in real language terms, you need to accept the fact that humanity has decided to call big boxes in server rooms "servers" and desktop computers on peoples' desktops "clients".

No, you have to accept that just because stupid people are stupid and wrong doesn't mean that words suddenly start to mean something else.

Stupid

[jmorris42]

> it seems like this could lead to an X-hosting renaissance of sorts,
> since you wouldn't be risking the whole system just to open up a
> specific user's account to remote X servers.

What a clueless statement. Somebody doesn't understand how X works. The server part that runs SUID root has never ran on the app server.

What this does do is stop a random remote app getting to root on your workstation but any local exploit of the X server gets them your user account and that can cause a lot of mischief and only needs a different local root exploit to get the rest of the way to 0wn1ng your local desktop machine.

Re:Stupid

[Freetardo Jones]

What a clueless statement. Somebody doesn't understand how X works. The server part that runs SUID root has never ran on the app server.

Yeah, the submitter is clearly clueless as is timothy since he couldn't notice such a glaring error.

What this does do is stop a random remote app getting to root on your workstation but any local exploit of the X server gets them your user account

Which is far less dangerous than them getting root access.

and that can cause a lot of mischief and only needs a different local root exploit to get the rest of the way to 0wn1ng your local desktop machine.

Which basically makes it harder for someone to get root access since they have to find another exploit to gain it.

Re:Stupid

[jmorris42]

> Yeah, the submitter is clearly clueless as is timothy since he couldn't notice such a glaring error.

Well the Slashdot editors went to the Grey Side (Mac) a decade ago so what the hell would they know about X. The /. servers are still *NIX so they know and care about that side a bit.

> Which basically makes it harder for someone to get root access since they have to find another exploit to gain it.

Sure, this move is a win for security because X was big complicated and running as root, but not cause for great rejoicing as at any point in time there is usually an unpatched local root exploit or two out in the underworld. We really need to worry more about security before we start hitting the lamestream media every few weeks..

Re:Stupid

[TheRaven64]

You can run X on OS X (I do) and it doesn't need root because it runs on top of a window server (which does run as root) that talks to the hardware. The Apple X11 implementation is not the best (it's based on an old version of X.org) but it's capable of running Xephyr if you need more features.

Re:Stupid

[maxwell demon]

What this does do is stop a random remote app getting to root on your workstation but any local exploit of the X server gets them your user account and that can cause a lot of mischief and only needs a different local root exploit to get the rest of the way to 0wn1ng your local desktop machine.

To your user account? I'd expect the non-root X server to usually run on its own user account.

Remote X servers?

[TerranFury]

I am a bit confused by the submitter's comment about remote X servers. I understand the appeal of remote X clients: I can, e.g., log into a big fast machine and run MATLAB (the X client) there while interacting with the window on my less-powerful laptop (which runs the X server). But what's the point of a remote X server? Why would anyone want to run an X server (software sense of 'server') on a server (hardware sense of 'server')?

Re:Remote X servers?

[Anonymous Coward]

Yo dawg we heard you like to remote so we put a server in your server so you can remote while you remote.

Re:Remote X servers?

[Anonymous Coward]

Submitter was confused about the role of X server. For the uninformed, the X "server" runs locally on the computer, and remote "clients" (e.g. executables) run on the local server.

Re:Remote X servers?

[Freetardo Jones]

It's not just the submitter. Apparently the writer of the blog post themselves don't even understand X all that well.

Re:Remote X servers?

[j_sp_r]

You don't need X for Matlab. The interface isn't that good.

Re:Remote X servers?

[nine-times]

I doubt I know enough to answer your question, but your question itself confuses me. You understand why someone would want to run "remote X clients", but you don't understand why someone would want to run "remote X servers". If you don't have a server, then who is the client connecting to?

Re:Remote X servers?

[TerranFury]

You don't need X for Matlab. The interface isn't that good.

It's for plots that having X is useful.

Re:Remote X servers?

[fikx]

you could conceivably have devices that use a common PC for their display, like a router whose config screen goes to the PC via X instead of a web app like today.... (pop-ups and such work much better this way than http). Or how about your TV or a video wall being a server for multiple apps?
Not real compelling uses I know, but starting to think in the right direction if we don't have to worry about rooting the machine by playing with these ideas...

Re:Remote X servers?

[TerranFury]

The "X server" runs on the machine with the keyboard, mouse, and display. An "X client" is a program (e.g., xterm) that connects to an "X server" to which it sends drawing commands and from which it receives mouse and keyboard events. In the "writing network software sense," these names make sense, because it is the "X server" that sits and listens on a port, and the "X clients" that connect to it. What makes this confusing is that in practice an "X server" will usually run on a user's machine (which you would normally call a 'client') and an "X client" will run on a big machine elsewhere (which you would normally call a 'server'). The problem comes from using the words "client" and "server" to describe both programs and machines; basically, our jargon sucks.

Re:Remote X servers?

[Anonymous Coward]

remote clients run on the local server.

Well, you've got to admit that this IS a bit confusing...

Re:Remote X servers?

[TerranFury]

What makes this even more confusing is the role of SSH (when it is used), so that servers and clients are actually connected via other proxy servers and clients running locally...

Re:Remote X servers?

[garbletext]

I just generate output graphics as files and open them on my machine over sftp. A whole X session seems like monstrous overhead for a transaction that is 99% text and an occasional image file.

Re:Remote X servers?

[stevied]

It's a truism: those who do not understand technology are destined to write clueless articles about it, apparently.*

Sorry, feeling particularly bitter and twisted this evening ..

(* or get appointed CTO)

Re:Remote X servers?

[TerranFury]

Hmm... What that lacks is the ability to interact with the plots (zoom in, etc), which I like sometimes... but on the plus side, as you said the overhead is lower, and also 'screen' will work (whereas the equivalent for X clients, 'xmove,' doesn't play nice with xauth, and anyway is rarely installed on servers to begin with).

A third method that a friend of mine uses (for very big jobs) is to have the MATLAB script generate emails; he just runs it with nohup and logs out.

Re:Remote X servers?

[TerranFury]

Hmm... yeah; that's the kind of stuff I was trying to think of (and I think it'd be cool if devices did this). But really you'd only need one X server for this, and there wouldn't even be much reason for it to be run by the user whose X client was connecting to it; that's all the sort of stuff that's already handled by xauth.

Re:Remote X servers?

[TerranFury]

The problem is that we use the words "client" and "server" to refer both to the programs and to the machines they run on. Usually server machines run server programs, but not always (and consider true P2P stuff where programs are both clients and servers). Maybe we need to throw out all the words and replace them with alternatives like "listener" and "caller" for the programs and... "big machine" and "little machine" for the computers? :-)

Re:Remote X servers?

[not-my-real-name]

A remote X-server is what runs the video wall. I can run the client program on my workstation and have it display on the wall.

Now, I just need to install the video wall in my underground lair.

Re:Remote X servers?

[Anonymous Coward]

There are occasional situations for having a X server on a 'sever computer', but none of which have needed to EVER be SetUID root anyway.

The VNC Server implementation on Linux is an X Server that you connect to using the VNC client, for example. (X window client programs connect to this and it looks, to them, like an ordinary X server. VNC client programs connect to this same program on the VNC port and it renders the X11 display into the VNC stream visible in the VNC client.)

Other possiblities: Xnest - the X window server that is also an X Window client.

But, since none of these do anything other than TCP IP communications, they've never needed root access ever. Stupid submitter.

Re:Remote X servers?

[Anonymous Coward]

Mod up. And bonus points for "basically, our jargon sucks".

Hopefully the next version of X will swap the names Client and Server so people won't be as confused.

Re:Remote X servers?

[Timothy Brownawell]

Maybe we need to throw out all the words and replace them with alternatives like "listener" and "caller" for the programs and... "big machine" and "little machine" for the computers? :-)

So what happens when you have a horribly overpowered gaming desktop and one of those dinky embedded "home NAS" things? :-p

Re:Remote X servers?

[smoker2]

No more confusing than running a web server on your local machine. You can connect to it using localhost, and see the same things others can see if you open the firewall, and expose that service. X is a server, whether you choose to expose it to the outside world is up to you. But just calling it a server alerts you to the possibilities, and gives an idea of how it works. Remember *nix was designed to be a networked system. There was a time when the X server would be on another machine. It is still capable of that, so why change the name ? Network transparency should be a good thing in this age of fast WANs. And a server doesn't have to be a big machine. Most web servers are actually no more than you have at home. There are more of them to separate tasks and load evenly that's all.

It's only people who don't know anything about the subject who would get confused, and it doesn't take much does it.

Re:Remote X servers?

[Anonymous Coward]

Now I am confused!

A web server can be used to display the output from FireFox?

The X Server should be called "daemon" or "service", not "server"

Re:Remote X servers?

[Anonymous Coward]

Well for everything other than X we use 'daemon' on *nix and 'service' on Windows so why not just stick with that?

Re:Remote X servers?

[maxwell demon]

Well for everything other than X we use 'daemon' on *nix and 'service' on Windows so why not just stick with that?

While probably all servers are run as daemons, not every daemon is a server. For example, it makes sense to run an NTP client as daemon, so that you can automatically keep your computer's clock synchronised with a remote NTP server.

And no, I haven't yet heared of "web daemons", "NNTP daemons" or "IRC daemons".

Re:Remote X servers?

[maxwell demon]

Now I am confused!

A web server can be used to display the output from FireFox?

The X Server should be called "daemon" or "service", not "server"

Since a web server is not a display server, it cannot be used to display. Just as the file server cannot be used to print, and the print server cannot be used to store files.

Another way to view it is to see that there's typically far less servers than clients. There are few file servers (often just one) managing the files for many clients working with the files. There are a few (maybe just one) print servers managing the printers for many clients who want to print. And there's typically one display server per desktop computer managing the display for many client programs which want to use that display.

Re:Remote X servers?

[bostei2008]

There is one exotic usage I have sometimes, if you want to give someone (eg an IT support person) access to your machine.

Just set the DISPLAY to his local box and let e.g. a root xterm pop up on his box. That way you don't have to give him the root password.

(of course there is nothing secure about this, it is only convenience)

Re:Remote X servers?

[jonadab]

> and consider true P2P stuff where programs are both clients and servers

In that case you just call them peers.

> replace them with alternatives like "listener"
> and "caller" for the programs

Okay, I could go along with that.

> "big machine" and "little machine" for the computers?

That could get confusing if the big machine is actually smaller than the little machine (e.g., a 1U rackmount big machine and a full tower little machine). Size isn't really the issue, so much as location.

Re:Remote X servers?

[Anonymous Coward]

And no, I haven't yet heared of "web daemons", "NNTP daemons" or "IRC daemons".

Uh, what do you think, exactly, the 'd' in httpd, nntpd and ircd stands for?

Re:Remote X servers?

[zippthorne]

It depends on what you're doing with matlab. If you're just futzing around with things, then you're not writing scripts, you're using the command line and checking what the equations look like every three or four lines of code. I'd say this covers at least 60% of undergrad student usage of matlab, which is likely the most common version, since the student version comes in at under $100 and the real version could be up in the thousands depending on what toolboxes you get. Otherwise octave would be a lot more popular.

Re:Remote X servers?

[vainvanevein]

local and remote would work better for the computers

Re:Remote X servers?

[fikx]

I'm not sure how the article worded it, but the real trick in this new development is not as "the user" as in the user running the client but "a user" meaning a non-root user. opening up an X server in the past (like for the uses I mentioned) always before forced you to rely on the app level security (X and xauth) to protect system level access (root) failure in the app level gave access to system level (root). Now you can run X as any user (not just root) so it's much safer now to run open X servers since you can run it under a restricted account. In the same way you can run apache using the "nobody" account you can also do the same with X now and now worry about you box putting a root program sitting on an open network port :)

Re:Remote X servers?

[Anonymous Coward]

re. IRC daemons: the term IRCd is in commonplace use, and stands for Internet Relay Chat daemon.

http://en.wikipedia.org/wiki/IRCd

And whilst I agree with you that most people would say 'usenet server' and 'web server', the fact is that the binaries are nntpd and httpd.

Anyway, this is beside the point, which is as you say that daemons don't have to be servers. A daemon is just anything that runs in the background. Servers tend to be things that run in the background, hence servers are usually daemons...

Re:Remote X servers?

[bill_mcgonigle]

Hopefully the next version of X will swap the names Client and Server so people won't be as confused.

Make the names wrong so people who don't understand will be 'right'? Puh-leeze.

A more precise name, perhaps.

Re:Remote X servers?

[Anonymous Coward]

google LTSP

cheers

Two questions:

[Anonymous Coward]

1. Does this mean you can't login at a graphical interface? I.e. will you have to login at a terminal and then wait for X server to come up?

2. If multiple users login, will each user get their own instance of X server? This seems like overkill...

Re:Two questions:

[Wesley Felter]

1. Does this mean you can't login at a graphical interface? I.e. will you have to login at a terminal and then wait for X server to come up?

No. There should be a login X server (running as root or nobody or whatever) to display GDM, then during login this server will exit and launch a new server under your uid. Or something like that.

2. If multiple users login, will each user get their own instance of X server? This seems like overkill...

I think fast user switching already works that way. We don't consider it overkill that each user gets their own instance of Firefox; why is X any different?

Re:Two questions:

[Anonymous Coward]

2. If multiple users login, will each user get their own instance of X server? This seems like overkill...

That's the way it works already. And why would it be a problem. Both X server processes will share the same (read-only) memory pages of program code. The stuff they don't share is the data, which is different for different "desktops" anyway. And users sharing a single instance of the x-server would be a security nightmare anyway. I think it would be rather trivial to install an X-based keyboard monitoring application that would log keyboard activity for whomever was the active user.

Re:Two questions:

[Anonymous Coward]

1. Does this mean you can't login at a graphical interface? I.e. will you have to login at a terminal and then wait for X server to come up?

No. There should be a login X server (running as root or nobody or whatever) to display GDM, then during login this server will exit and launch a new server under your uid. Or something like that.

So how do secure logins work? How am I sure whether a graphical login screen is genuine or a spoofed page put up by another user?

Windows requires secure login keys (Control-Alt-Delete) that only the kernel can intercept before showing a login prompt.

Re:Two questions:

[zippthorne]

security will always require a replication of effort beyond the otherwise economically efficient level. But the cost buys you piece-of-mind, so it's still worth it. And may be partly mitigated by copy-on-write.

Also, there's no reason that the login has to be a terminal. It could just run as nobody.

Re:Two questions:

[bluefoxlucid]

This is a dumb question, and you are dumb for asking it. Try software upping CTRL or ALT before DELETE is pressed.

Re:Two questions:

[Anonymous Coward]

Also, note that 2 people with their "own instance of X server" doesn't mean it takes twice the memory of a single X server. A lot of the code pages are shared.

Graphics drivers

[Chemisor]

If graphics drivers were implemented in the kernel instead of the X server, this problem wouldn't have existed in the first place.

Re:Graphics drivers

[Wesley Felter]

Yes, it's interesting that KGI was rejected 10 years ago, but now we have KMS. What has changed?

Re:Graphics drivers

[Anonymous Coward]

It's been 10 years. Duh.

Re:Graphics drivers

[Hatta]

If graphics drivers were implemented in the kernel instead of X, you would have to write new drivers for every kernel you want to run X on.

Re:Graphics drivers

[Wesley Felter]

We have that situation for all other drivers and somehow we survived. Also, it's common for vendors to write a single BSD-licensed driver and then port it to multiple OSes, sharing most of the code.

Re:Graphics drivers

[sofar]

KGI replaces X, KMS only implements the hardware-specific parts in the kernel, while keeping the entire Xorg userspace (the real "graphics" parts) in userspace.

Re:Graphics drivers

[Freetardo Jones]

What has changed?

The fanatics have become more reasonable?

Re:Graphics drivers

[stevied]

Linus isn't perfect. His opinions evolve over time. On the whole, though, his intuitive sense of taste has been for Linux, I reckon.

Also, I think KGI wanted to push a lot more into kernel space that we have now, even with kernel mode-setting, though my aging memory may well fail me..

Re:Graphics drivers

[kelnos]

What, people aren't allowed to change their minds about something given 10 years of new information?

Re:Graphics drivers

[kelnos]

That's already been the case for the more mainstream cards (nvidia, AMD, Intel) for many years now. They all require a kernel piece for 3D support. nvidia, at least, has a single driver core that they use for multiple OSes, with a little translation layer for the particular kernel. I don't know what the others do.

Re:Graphics drivers

[Anonymous Coward]

Linus isn't perfect

I met Linus in person a while back and asked him about this. He disagrees with you.

Since he's perfect, I kinda have to go with him on this one.

Re:Graphics drivers

[TheRaven64]

KGI was a massively-complicated API which failed to actually expose the useful features of the hardware, while KMS allows the same userspace device drivers (with a small amount of kernel-mode validation, for example of DMA requests) that X11 already uses but removes the need for X11 to be run as root and makes virtual terminals and power saving play nicely with X11.

Re:Graphics drivers

[stevied]

On the whole, though, his intuitive sense of taste has been for Linux

s/been/been pretty good/

Proof-reading ability falls off with increasing blood alcohol levels, sadly ..

Re:Graphics drivers

[Anonymous Coward]

"Linus isn't perfect"

Somebody should tell this to his acolytes. It would save a lot of time.

Re:Graphics drivers

[bXTr]

That would be great if you're running Linux, but not *BSD or *nix. People seem to forget that X is not a Linux-only application.

Re:Graphics drivers

[zippthorne]

Well, that certainly begs the question; How do you know he's telling the truth?

Re:Graphics drivers

[Rich0]

Exactly. This is why x.org also implements its own TCP stack and network drivers. It isn't like it is possible to design some kind of standard interface so that an application could open a TCP socket on two different operating systems!

Somebody just needs to define a standard for accessing graphics cards via a unix-like operating system and then everybody can code to the standard.

Re:Next step

[miknix]

chroot jail the X server.

Any X/Windows Programmer Knows ....

[Anonymous Coward]

Any X/Windows Programmer Knows that the X/Server is on your desktop and the X/Client runs on the server. Duh. http://en.wikipedia.org/wiki/X_Window_System has a nice diagram on the right hand page.

See, that $10k X/Windows class my previous, previous, previous employer paid for 15 years ago WAS useful. Sadly, at the time, we elected to be cross platform and used XVT and Galaxy for development instead of X/Windows (Xlib, X/Motif, X/Intrinsics)

Anyone else remember the 1993 Jolt Winner Visix/Galaxy? That GUI builder rocked!

Anyone wanna buy some "vintage" X/Windows programming manuals? I have the complete set including 6a and 6b!

Is this right ?

[bytesex]

I am not sure that this is the right solution. Not running it as root is good, but running it as me - I don't know. I'd rather that the user that runneth the X server is some sort of 'xserver' user - to whose process I connect. That 'xserver' user then has the right to push my screen into VGA mode and all that. Also, this doesn't fix all those other services (that gnome has, for example) that allow my X programs to mount stuff etc. Which is, again, a security risk by itself.

Re:Is this right ?

[drsmithy]

Not running it as root is good, but running it as me - I don't know. I'd rather that the user that runneth the X server is some sort of 'xserver' user - to whose process I connect.

So if you have multiple users on the same machine running X, they can stomp on each other (by virtue of all interacting with the same "xserver user") ?

Re:Is this right ?

[stevied]

I don't see the problem, to be honest. the toolkit libraries of your apps (by definition running as you) turn requests for widgets into drawing primitives and pixels that need setting in a framebuffer. The X server draws them / sets them. What's the third level of protection protecting you against? Processes memory contents are already protected against each other, the worst the X server might be tricked into doing is reporting the window or clipboard contents of one app to another, which is usually something you want it to be able to do anyway.

There's a possible argument for being able to mark certain X clients as "sandboxed" in the X server, but running the X server as a separate user isn't going to help in that situation - just introduce more complexity.

Re:Is this right ?

[kelnos]

I am not sure that this is the right solution. Not running it as root is good, but running it as me - I don't know. I'd rather that the user that runneth the X server is some sort of 'xserver' user - to whose process I connect. That 'xserver' user then has the right to push my screen into VGA mode and all that.

As another poster mentioned, this makes multi-user X a bit more difficult. What's the issue of having your user ID doing all this? If you're allowed to log into the console, then you're presumably allowed to run X (or not; you can still lock down the machine so particular users can't run X or access the graphics hardware). If you can run X, you can talk to the graphics hardware. Note that this doesn't give you carte-blanche to fiddle with the graphics card's registers to try to make the machine crash: you only get certain actions as provided by the DRI interface.

Also, this doesn't fix all those other services (that gnome has, for example) that allow my X programs to mount stuff etc. Which is, again, a security risk by itself.

No, you just don't understand how it works. X apps do not mount things. HAL (or, soon, DeviceKit-disks) mounts things on behalf of authenticated requests from X apps (or console apps, even). HAL/DeviceKit are system daemons that have no GUI. Frameworks like PolicyKit and ConsoleKit ensure that you aren't mounting or unmounting things you shouldn't be.

Re:Is this right ?

[davidsyes]

Stomping? Do we have that problem other apps that use the /temp directory?

Recently, i upgraded my Mandriva 2009.0 to 2009.1, and some how the permissions on my /temp path were mangled after the upgrade. I could not open KDE. Sure as hell, when i changed the permissions to that of the user i logged in as, i got to the desk top just fine.

BUT, log out of one account and into another account? Same problem. If i changed the perms on /temp to THAT user, then the problem went away. I said fsck it and (since it's my laptop) did chmod 777 on the /temp folder. I wasn't quite comfortable tho, as any exploits hitting a user im in now might propagate to another account, i fear (grounded or not...).

Re:Is this right ?

[Anonymous Coward]

Stomping? Do we have that problem other apps that use the /temp directory?

Theoretically we would. But first consider that file and directory permissions are not the same thing as UIDs, which is what the GP was talking about. A world readable or even writeable directory is not the exact same thing as having multiple users share a UID.

BUT, log out of one account and into another account? Same problem. If i changed the perms on /temp to THAT user, then the problem went away. I said fsck it and (since it's my laptop) did chmod 777 on the /temp folder. I wasn't quite comfortable tho, as any exploits hitting a user im in now might propagate to another account, i fear (grounded or not...).

You really should educate yourself on the "sticky bit" some time.before continuing to make a fool of yourself on this topic.

Re:Is this right ?

[drinkypoo]

What's the issue of having your user ID doing all this?

A remote hole in a process run as 'nobody' allows some log files to be trashed, maybe.

A remote hole in a process run as me allows all of my data to be destroyed.

Re:Is this right ?

[Lennie]

I guess we all need xusername users so everyone has a seperate user to run X. ;-)

Re:Is this right ?

[Anonymous Coward]

Wouldn't that be fairly easy to prevent, though? The xserver-user could be disallowed write access to its own files, and settings would be read from the real users' home directories.

Re:Is this right ?

[Ash-Fox]

It prevents any exploits for the xserver user from being able to effect the rest of the system outside of the confines of the user and whatever it can interface with graphically. Thus preventing it from gaining control to the rest of the system easily. Plus, selinux, apparmor can likely be enhanced to enforce the rules upon the xserver in other ways when it is running as a user process.

Re:Is this right ?

[vainvanevein]

I see no advantage to having the the X Server running as an "xserver" user versus running as a regular user. If there isn't an advantage, then its an unnecessary complication.

Re:Is this right ?

[kelnos]

How is a remote hole going to be exploited given that most (if not all) Linux distros I know about ship X with '-nolisten tcp' set by default?

Re:Is this right ?

[Anonymous Coward]

I wish slashdot had a -1 wrong mod. Slackware doesn't. Also, attackers don't just want to run botnets on your machine. They also want to copy data they can exploit. Such as bank logins and credit card numbers. There are also vandals too. They are just not as numerous or skilled compared to organized crime.

Then the submitter was saying this is a "decades old" X server problem. No it isn't. Maybe it is a decade old problem, becuase I think around the time, 3D acceleration and DRI became important, and it required root access to work. Before then, I had no trouble running an X server as a regular user.

Now if they will just allow the root filesystem to be mounted read-only. Ever since the dbus/hald crap was put into slackware, it doesn't work. I don't think it would even finish booting if I set up / to be read-only.

Re:Is this right ?

[multi io]

What's the third level of protection protecting you against?

You could set the permission bits of the graphics device such that only the "xserver" user can directly do the modeswitching and graphics/framebuffer manipulation stuff. This would prevent arbitrary user A from disrupting the display of user B (who is currently running an X session) by randomly resetting the mode of the graphics device. Even if the device were designed to exclusively grant access to the first user who opens it and lock out everyone else, you would still want that first user to be the dedicated "xserver" user rather than some arbitrary user who managed to come first in a multi-user installation.

Re:Is this right ?

[kelnos]

So you find one single example and decide I'm wrong? Nice try.

Re:Next step

[d3matt]

that wouldn't really work. you still need (without kernel modesetting) access to the graphics hardware.

Been waiting for this

[gweihir]

X is a large, clutterd and complex system that has no business running as root. It is good to see they finally managed to get away from that implementation, even if it adds a bit more complexity.

Re:Been waiting for this

[John Hasler]

It looks like they have done this by pushing the hard parts into the kernel. I'm not sure this doesn't make security worse.

Re:Been waiting for this

[Anonymous Coward]

Advantage is that it gets audited.
By moving to kernel it doesn't automatically make it secure, but this new graphic system model should be more secure, just by design. With GPU memory management it should be harder to lock than the system using DRI v1, which was based on cooperative graphical resource and time sharing. There are similar issues for modesetting. Clearly most hardware is still limited, so you can't prevent all this from happening, but hardware designed for LDDM 2.0 (vista and windows 7) driver model should be capable of fully virtualising contexts regardless of how they behave.

Re:Next step

[miknix]

Sorry, I forgot to enable the [sarcasm] flag.

What about the rest of X?

[Anonymous Coward]

Have they fixed the completely backwards and useless clientserver architecture? No? Why the fuck not?

There is no need for an "X Server" to run at all if you can't disconnect a client from one and add it to another, multicast, etc. Basically, anything Screen can do, if X can't do, it's stupid.

Re:What about the rest of X?

[Ash-Fox]

Have they fixed the completely backwards and useless clientserver architecture? No? Why the fuck not?

There is no need for an "X Server" to run at all if you can't disconnect a client from one and add it to another, multicast, etc. Basically, anything Screen can do, if X can't do, it's stupid.

I did this long ago, can't remember what the software package was called now that allowed stateless x11 usage. Essentially a client could disconnect, reconnect, have multiple clients to the same xsession etc. Just like screen.

And it was x11, not VNC.

Network drivers

[Chemisor]

Funny how somebody has to write network card drivers for every OS your browser runs on. It's a wonder why nobody has considered putting those drivers in the browser instead.

Re:Network drivers

[TheRaven64]

Take a look at the drivers for a simple network card and a simple GPU. Even something like the i830 is a couple of orders of magnitude more complex than something like a RTL8139 network interface.

Re:Network drivers

[hazah]

That's not the point.

It's "X Window System", not "X Windows"

[Anonymous Coward]

Sorry for nit picking, but this seems to have been lost on the people who tagged "xwindows".

Have you used Moblin?

[SlickSlacker]

I just loaded it on my Eee PC and it turns the machine into a kiosk. Very unappealing for anyone who actually wants to use their netbook. Its very flashy and friendly if all you do is check your email and browse the web though.

Re:Have you used Moblin?

[Freetardo Jones]

Its very flashy and friendly if all you do is check your email and browse the web though.

Almost like that was the entire point of the distro in the first place!

Re:Have you used Moblin?

[Calithulu]

I'll be doing this tonight. I want something light weight and easy to use for web browsing and email when guests come over or for when I travel.

Re:Have you used Moblin?

[spikeb]

wish it ran on eee 701 models, perfect for that heh

Re:Have you used Moblin?

[jhfry]

Since you have tried it, can you answer a couple of questions.

1 - can you open a shell/terminal window?
2 - can you create custom application launchers

If so, how is it so unappealing. Perhaps you just need to customize it a little to make your needs more accessable. If not, then you have saved me the effort of giving it a try.

Re:Have you used Moblin?

[Tacvek]

I've not used it, but the following is my understanding based on the website:

Moblin is designed to support social networking, media viweing/playing, and web browsing.

Social networking integration is a main point. Update your flicker status from a drop-down panel of the main toolbar.

For media viewing the system intends to allow to to browse local and remote media, with integration with services like flicker and last.fm.

I did not see any IM integration in the short introduction video, although it is a fairly obvious idea. The status panel provides the obvious place to adjust IM status, and the people panel would be an obvious way to launch an IM conversation with somebody.

For web browsing it provides an integrated web-browser based on Gecko (the rendering engine found in Firefox). A decent web-browser is actually very uncommon in integrated environments like Moblin.

If you want to do just about anything else, you must either use the web-browser to do it, or launch a regular Linux application, in which case, as always, the entire experience falls apart.

I know many people who really don't use their computers for anything else, with the exception of some limited Word processing style work. If Google Docs is sufficent, then it might be a decent OS for them, once it has support for their favorite social networking sites fully integrated, and more kinks worked out.

Even those who do use their computer for more, they are not likely to use their netbook for that. After all these are exactly the sort of things a netbook is marketed for.

So the grandparent is using his netbook for more than it is marketed for. So when he tries an OS designed specifically around what netbooks are marketed for, he is not satisfied. Big surprise!

Re:Have you used Moblin?

[Hawke666]

yes on both counts.

Re:Have you used Moblin?

[jhfry]

So, essentially if you "really want to use your netbook" it only takes a bit of tweaking to make it do the same things as any other netbook. Sounds like the GP didn't give it a fair shake.

Re:Have you used Moblin?

[Hawke666]

Pretty much. Although to be fair, custom applications have kind of "second class citizen" status compared to the built-in applications.

SELinux

[FranTaylor]

Except on any decent Linux distribution, the X server is running inside SELinux and is really not capable of doing much at all.

Re:Poor understanding of X OT/Reversibles?

[davidsyes]

Technically off-topic, but to use the one of words as is, and another replaced by its analog...

>"The client tells the server what to do."

Imagine if history were revised such that "The SLAVE tells the MASTER what to do.", without reversing the definition of "master" and "servant" (well, unless it's done by Depeche Mode...). The world would be farther along, maybe.

I don't know...

[earnest murderer]

Certainly this isn't worse than the current situation. But if my data is still at risk I have a hard time caring much about any "security" advantage.

Without my data the machine is worse than worthless.

Re:I don't know...

[kelnos]

The "security" advantages you so easily dismiss are the things that tend to safeguard your data. Most desktop X servers out there run with network access disabled. At least this way if someone breaks into your machine via other means, they can't find a vulnerability in the X server to gain root.

Most attackers don't break into your machine to trash your data. They're there to take over it and turn it into a zombie for their botnet. Trashing your data is actually counter-productive; they want to hide their intrusion.

Not exactly innovative.

[wkcole]

On MacOS X, the X server also runs as the logged-in user. It isn't clear what "nerdyH" means by its last sentence, which doesn't really make a lot of sense. No one who cares about security puts unshielded X Windows sessions on insecure networks, because X Windows data streams between clients (e.g. xterm, Firefox, the Gnome or KDE desktops, or almost anything graphical on any Linux machine) and display servers (the piece that 'serves' a display device to clients) are not encrypted. Remote X Windows sessions are usually kept on private networks or tunneled through SSH. What this protects against is not snooping, but rather against some as-yet-unknown bug in the X server allowing code injection as root. That's a good thing, but it isn't huge. For a system distro, it could be made meaningless by the integrator giving the logged-in user excessive capabilities. To balance my first sentence: Apple provided examples of that in early versions of MacOS X, where file and directory permissions made privilege escalation trivial.

Re:Not exactly innovative.

[MichaelSmith]

Tracking down a bug at work I once downloaded the sources for X11. I can't recall if it was XFree or X.org which I got but what I saw was scary. Its all old school C. Functions trust the array indices they are given. Bounds checking is rarely done. I was eventually able to prove that the code I investigated was correct, but it took a lot of head scratching to get that far.

Re:Not exactly innovative.

[kasperd]

On MacOS X, the X server also runs as the logged-in user.

That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens to be implementing X on top of X, but it still doesn't need special privileges since it isn't controlling the hardware itself).

Re:Not exactly innovative.

[wkcole]

On MacOS X, the X server also runs as the logged-in user.

That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens to be implementing X on top of X, but it still doesn't need special privileges since it isn't controlling the hardware itself).

Well, yes, that was the point: GUI architectures that don't require a monolithic process running as root to do everything between the physical display and application code are not new. On MacOS and Darwin, X11 runs as the logged in user and like all other apps that need to draw or get keyboard and mouse events, it talks to WindowServer *which runs as a restricted user* and itself isn't handling hardware directly. That architecture is a descendant of NextStep, i.e. it predates Linux.

Mac OS X does this too !

[Anonymous Coward]

Huh ? I think Mac OS X does this too.
I just started an X-windows app on my Mac (10.5.7).
There are 3 X processes with sequential PIDs -- xinit, Xquartz, and X11.
All show the user as me, NOT root.

3d graphs

[Anonymous Coward]

3d graphs

Untrue

[Anonymous Coward]

Your observation that in todays networks latency is more important than bandwith is correct. But if you benchmark recent cairo/XRENDER against VNC you will find no difference.

It is true that some widget libraries like GTK, and especially ECLIPSE SWT use round-trips excessively, making them unusable in network environments..

I think it's a library problem, not X. "Succcessors" like http://y-windows.org/ for example promote server-side widgets instead, essentially using expensive round-trips for everything.

X11 is the only technology allowing individual applications to direct their output to remote screens. But they have to be written with this in capability mind. If you use a widget library which makes use of cairo/XRENDER, there shouldn't be a problem at all.

Why not take it one step further?

[kasperd]

Since there was never any reason for the X server and the clients to need to use the same uid, why move the X server from root to the logged in user? It could as well be moved from root to a uid dedicated to the X server. Then you would get another level of separation, at essentially no price. (There is of course a caveat in case you have multiple X servers running at the same time, but that could be solved by allocating a uid per X server).

Does graphics mode switching inside the kernel mean that we can soon expect switching between VTs to work even if the X server is locked up? Or is the keyboard handling still going to prevent that? (Doing the switching from a remote login would work around the keyboard issue).

Re:Why not take it one step further?

[vainvanevein]

That extra level of seperation would add no security benefits, so would be unnecessary.

Re:Why not take it one step further?

[bill_mcgonigle]

That extra level of seperation would add no security benefits, so would be unnecessary.

Are you assuming an X implementation firewalled from the network? One nice X network exploit and whichever user is running X has his home directory open for anonymous access.

Re:Why not take it one step further?

[Anonymous Coward]

Most distros disable TCP listening for X by default, so X doesn't even need to be firewalled as it is not listening on the network, it is only listening via the local Unix sockets. This will stop all X network exploits.

Punctuation Police (Re:X Hosting?)

[Shin-LaC]

Don't separate restrictive relative clauses with commas. For example:

because the networks, for which X was designed, did not have "significant" latency

This should be: because the networks for which X was designed did not have "significant" latency.

That loose synchronization is the price, that X-windows designers did not want to pay.

This should be: That loose synchronization is the price that X-windows designers did not want to pay.

Re:Punctuation Police (Re:X Hosting?)

[mi]

Don't separate restrictive relative clauses with commas.

The commas do belong there in Ukrainian and Russian — my first two languages — and seem to keep the sentences clearer in English too...

Re:Punctuation Police (Re:X Hosting?)

[Anonymous Coward]

> The commas do belong there in Ukrainian and Russian -- my first two languages -- and seem to keep the sentences clearer in English too...

Try using parentheses. You may be pleased with the results!

The Really Cool Thing

[Anonymous Coward]

Besides the fact that it's just cleaner to have the X server running as non-root, this opens the door for some interesting experiments. Want to experiment with how responsibilities are distributed within the desktop environment? This is now easier than ever.

For example, what about a plugin system in the X server that allows you to run e.g. compositing and window manager in the server, thus eliminating a whole crapload of race condition headaches? Previously that would have been insanity, and it's still not clear that it's a very good idea. But now it's at least possible.

SunOS and Solaris have always operated this way.

[efalk]

I was a video driver developer for Sun for many years. The window system *always* ran as the logged-in user. When I started developing for Linux, I was appalled when I realized that Linux ran the windows server as root.

Here's how we did it at Sun: For every supported video card, there is a device driver. The driver provides basic services such as cursor and color-table management (there are advantages to doing this in the kernel), and additionally allows the user logged in at the console to map in the device registers. This means that the window system doesn't need any special privileges to run.

There are other advantages to having a device driver manage user-level hardware mapping. Not the least of which is that it allowed us to implement full-bore context switching at the device level. The advantages of this are enormous.