Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted more than 5 years ago | from the such-a-little-thing-makes-such-a-big-difference dept.

X 205

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."

cancel ×

205 comments

Sorry! There are no comments related to the filter you selected.

frost nixon (1, Funny)

Anonymous Coward | more than 5 years ago | (#28642129)

frost nixon

Re:frost nixon (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28642217)

Long standing security issues with Linux? I thought the Lunix fanbois told me that it was the most secure OS of all time and yet they lied to me about something as dangerous as this bug? I guess I'll go back to my "insecure" Windows XP box that doesn't run the windowing system as the root user.

Re:frost nixon (4, Insightful)

msuarezalvarez (667058) | more than 5 years ago | (#28642279)

It doesn't?

Re:frost nixon (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28642875)

Windows is so secure it doesn't even have a root user! I'm not sure you're being sincere, but I'll assume that you are and answer you honestly: no, Windows runs the windowing system as the admin user. Idiot.

Re:frost nixon (4, Insightful)

Zero__Kelvin (151819) | more than 5 years ago | (#28643525)

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 (1)

Philip K Dickhead (906971) | more than 5 years ago | (#28642225)

Xroaches [unm.edu] just lost a lot of value.

Re:frost nixon (1, Informative)

mehemiah (971799) | more than 5 years ago | (#28644093)

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

IMHO (1)

rodgster (671476) | more than 5 years ago | (#28642131)

This is something that is long overdue.

Re:IMHO (1)

digitalunity (19107) | more than 5 years ago | (#28642237)

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 (5, Informative)

jmorris42 (1458) | more than 5 years ago | (#28642309)

> 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 (2, Interesting)

afidel (530433) | more than 5 years ago | (#28643027)

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 (4, Informative)

jmorris42 (1458) | more than 5 years ago | (#28643417)

> 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 (3, Interesting)

Enleth (947766) | more than 5 years ago | (#28642327)

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 (2, Insightful)

sofar (317980) | more than 5 years ago | (#28643107)

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

Re:IMHO (0)

Anonymous Coward | more than 5 years ago | (#28643459)

Ya think? X is older than I am.

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

Re:IMHO (0, Troll)

TheRaven64 (641858) | more than 5 years ago | (#28643445)

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 (0)

Anonymous Coward | more than 5 years ago | (#28644181)

get over yourself

One of the shortcommings in security (1)

santax (1541065) | more than 5 years ago | (#28642189)

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 (5, Informative)

Freetardo Jones (1574733) | more than 5 years ago | (#28642243)

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:Next step (1)

miknix (1047580) | more than 5 years ago | (#28642515)

chroot jail the X server.

Re:Next step (1)

d3matt (864260) | more than 5 years ago | (#28642755)

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

Re:Next step (1)

miknix (1047580) | more than 5 years ago | (#28643061)

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

Re:One of the shortcommings in security (4, Informative)

Timothy Brownawell (627747) | more than 5 years ago | (#28642249)

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 (1)

santax (1541065) | more than 5 years ago | (#28642969)

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

Re:One of the shortcommings in security (1)

ls671 (1122017) | more than 5 years ago | (#28644069)

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 (2, Insightful)

Hatta (162192) | more than 5 years ago | (#28642843)

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 (1)

sofar (317980) | more than 5 years ago | (#28643133)

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 (2, Informative)

kelnos (564113) | more than 5 years ago | (#28643391)

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 (1)

Hatta (162192) | more than 5 years ago | (#28644095)

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 (1)

dgatwood (11270) | more than 5 years ago | (#28643245)

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 (3, Interesting)

TheRaven64 (641858) | more than 5 years ago | (#28643493)

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.

Confused article. (5, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#28642227)

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.

X Hosting? (4, Informative)

Microlith (54737) | more than 5 years ago | (#28642231)

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? (2, Insightful)

John Hasler (414242) | more than 5 years ago | (#28643551)

> 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? (1)

ls671 (1122017) | more than 5 years ago | (#28644129)

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

correct !!!

Correct me if im wrong (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28642235)

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 (4, Informative)

metamatic (202216) | more than 5 years ago | (#28642451)

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.

Poor understanding of X (5, Informative)

Anonymous Coward | more than 5 years ago | (#28642245)

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 (4, Informative)

Nutria (679911) | more than 5 years ago | (#28642337)

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 (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28642465)

How is this backwards?

It's only backwards in human thought

In other words, it's not backwards at all, and anyone who "thinks" it is is simply wrong.

Re:Poor understanding of X (0)

Anonymous Coward | more than 5 years ago | (#28643375)

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.

Any X/Windows Programmer Knows .... (0)

Anonymous Coward | more than 5 years ago | (#28642537)

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 [wikipedia.org] 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!

Re:Poor understanding of X (0)

stevied (169) | more than 5 years ago | (#28643317)

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 (1)

TheRaven64 (641858) | more than 5 years ago | (#28643521)

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

Re:Poor understanding of X (0, Redundant)

John Hasler (414242) | more than 5 years ago | (#28643607)

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 (0)

glassware (195317) | more than 5 years ago | (#28643755)

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 (1, Informative)

Anonymous Coward | more than 5 years ago | (#28643845)

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 OT/Reversibles? (1)

davidsyes (765062) | more than 5 years ago | (#28643857)

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.

Stupid (3, Informative)

jmorris42 (1458) | more than 5 years ago | (#28642283)

> 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 (1)

Freetardo Jones (1574733) | more than 5 years ago | (#28642331)

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 (2, Insightful)

jmorris42 (1458) | more than 5 years ago | (#28642457)

> 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 (1)

TheRaven64 (641858) | more than 5 years ago | (#28643547)

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.

SELinux (1)

FranTaylor (164577) | more than 5 years ago | (#28643341)

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

Remote X servers? (3, Informative)

TerranFury (726743) | more than 5 years ago | (#28642289)

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? (0)

Anonymous Coward | more than 5 years ago | (#28642323)

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? (0)

Anonymous Coward | more than 5 years ago | (#28642333)

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? (3, Informative)

Freetardo Jones (1574733) | more than 5 years ago | (#28642377)

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? (0)

Anonymous Coward | more than 5 years ago | (#28643055)

remote clients run on the local server.

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

Re:Remote X servers? (4, Insightful)

TerranFury (726743) | more than 5 years ago | (#28643685)

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? (1)

j_sp_r (656354) | more than 5 years ago | (#28642587)

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

Re:Remote X servers? (1)

TerranFury (726743) | more than 5 years ago | (#28642923)

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? (1)

garbletext (669861) | more than 5 years ago | (#28643253)

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? (1)

TerranFury (726743) | more than 5 years ago | (#28643541)

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? (1)

nine-times (778537) | more than 5 years ago | (#28642689)

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? (3, Informative)

TerranFury (726743) | more than 5 years ago | (#28643003)

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? (1)

TerranFury (726743) | more than 5 years ago | (#28643079)

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? (1)

fikx (704101) | more than 5 years ago | (#28642989)

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? (1)

TerranFury (726743) | more than 5 years ago | (#28643657)

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? (1)

stevied (169) | more than 5 years ago | (#28643351)

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? (2)

not-my-real-name (193518) | more than 5 years ago | (#28643991)

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? (0)

Anonymous Coward | more than 5 years ago | (#28644155)

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 [wikipedia.org] - 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.

Two questions: (0)

Anonymous Coward | more than 5 years ago | (#28642307)

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: (3, Insightful)

Wesley Felter (138342) | more than 5 years ago | (#28642551)

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?

Graphics drivers (5, Insightful)

Chemisor (97276) | more than 5 years ago | (#28642433)

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 (3, Interesting)

Wesley Felter (138342) | more than 5 years ago | (#28642609)

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

Re:Graphics drivers (0)

Anonymous Coward | more than 5 years ago | (#28642639)

It's been 10 years. Duh.

Re:Graphics drivers (1)

sofar (317980) | more than 5 years ago | (#28643209)

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 (2, Insightful)

Freetardo Jones (1574733) | more than 5 years ago | (#28643323)

What has changed?

The fanatics have become more reasonable?

Re:Graphics drivers (1)

stevied (169) | more than 5 years ago | (#28643409)

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 (3, Funny)

Anonymous Coward | more than 5 years ago | (#28643511)

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 (1)

stevied (169) | more than 5 years ago | (#28643965)

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 (1)

kelnos (564113) | more than 5 years ago | (#28643461)

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

Re:Graphics drivers (4, Insightful)

TheRaven64 (641858) | more than 5 years ago | (#28643613)

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 (2, Insightful)

Hatta (162192) | more than 5 years ago | (#28642883)

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 (2, Insightful)

Wesley Felter (138342) | more than 5 years ago | (#28642951)

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.

Network drivers (1)

Chemisor (97276) | more than 5 years ago | (#28643179)

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 (1)

TheRaven64 (641858) | more than 5 years ago | (#28643649)

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:Graphics drivers (1)

kelnos (564113) | more than 5 years ago | (#28643499)

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.

Is this right ? (4, Interesting)

bytesex (112972) | more than 5 years ago | (#28642641)

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 ? (1)

drsmithy (35869) | more than 5 years ago | (#28642845)

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 ? (0)

davidsyes (765062) | more than 5 years ago | (#28643975)

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 ? (1)

stevied (169) | more than 5 years ago | (#28643507)

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 ? (2, Insightful)

kelnos (564113) | more than 5 years ago | (#28643567)

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.

Been waiting for this (1)

gweihir (88907) | more than 5 years ago | (#28642765)

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 (1)

John Hasler (414242) | more than 5 years ago | (#28643661)

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.

What about the rest of X? (0)

Anonymous Coward | more than 5 years ago | (#28643071)

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.

It's "X Window System", not "X Windows" (0)

Anonymous Coward | more than 5 years ago | (#28643313)

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

Have you used Moblin? (5, Informative)

SlickSlacker (568960) | more than 5 years ago | (#28643319)

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? (4, Insightful)

Freetardo Jones (1574733) | more than 5 years ago | (#28643385)

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? (1)

Calithulu (1487963) | more than 5 years ago | (#28644041)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>