bob@acornrc.UUCP (Bob Weissman) (04/19/88)
We must have done something wrong installing X11R2 on our Sun 3/60
running SunOS 3.4.
The server (Xsun) seems to run properly only when setuid root.
We don't mind this so much, but it's a problem when you want to
kill the server by having the distinguished first application exit.
It can't kill a server running as root.
It's simple enough to write a setuid server-killer, but I figure
there must be a better solution. Can anyone help?
--
Bob Weissman
Internet: bob@acornrc.uucp
UUCP: ...!{ ames | decwrl | oliveb | apple }!acornrc!bob
Arpanet: bob%acornrc.uucp@ames.arc.nasa.govjef%lbl-helios@LBL-RTSG.ARPA (Jef Poskanzer) (04/19/88)
Bob Weissman writes: >The server (Xsun) seems to run properly only when setuid root. >We don't mind this so much, but it's a problem when you want to >kill the server by having the distinguished first application exit. >It can't kill a server running as root. >It's simple enough to write a setuid server-killer, but I figure >there must be a better solution. Can anyone help? Yes, with a stock server, you must run both the server and xinit setuid to root. This is not really acceptable, especially since xinit's security hole re-appeared in this version. (I sent in a bug report about this within days of the X.V11R2 release, but have yet to see a patch appear. Unless I'm being dense this is a REALLY SERIOUS BUG. Get with it guys.) Anyway, what you can do is add a single "setuid( getuid( ) );" to the server just before it calls dispatch(). Then you install it setuid to root as before, but as soon as it's finished initializing it un-setuids itself. With this hack, xinit does not need to be root and there is no problem killing the server and NO security hole. --- Jef Jef Poskanzer jef@lbl-rtsg.arpa ...well!pokey "Sendmail may be safely run set-user-id to root." -- Eric Allman, "Sendmail Installation Guide"
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (04/19/88)
Date: Mon, 18 Apr 88 19:46:49 PDT
From: Jef Poskanzer <jef%lbl-helios@lbl-rtsg.arpa>
Yes, with a stock server, you must run both the server and xinit setuid
to root.
The wonderful thing about Unix environments is that no two are ever
alike. I don't think I've ever had to run either of these setuid on any
Sun on campus.
Anyway, what you can do is add a single "setuid( getuid( ) );" to the
server just before it calls dispatch().
The problem with this is that it works fine under xinit, where the
server isn't expected to loop, but it may fail for servers run from
init, where reinitialization takes place. Also, who is to say the ddx
code won't later need setuid privilege to get access to something, like
perhaps a restricted ioctl? Remember, you are changing dix code here;
you can't blindly change things because they happen to work for a
particular ddx.
With this hack, xinit does not need to be root and there is no problem
killing the server
Except of course when the server hangs initing devices or sockets or
extensions, which is where it often hangs on me ...dshr@SUN.COM (David Rosenthal) (04/19/88)
The only reason ever advanced to my knowledge for running the X server SUID root is that /dev/fb (or /dev/bwtwo0, etc.) is read-write only for root. /dev/fb (etc.) should be mode 666. The latest /dev/MAKEDEV sets it this way. The only thing a spoofer can do with access to /dev/fb is to mung bits on the screen, and the spoofer can do that with X anyway. It is much less of a security risk to have /dev/fb 666 than to have SUID root programs lying around. I strongly recommend people NOT to run the X server nor xinit as root. David.
jef@LBL-RTSG.ARPA (Jef Poskanzer) (04/19/88)
>The wonderful thing about Unix environments is that no two are ever >alike. I don't think I've ever had to run either of these setuid on any >Sun on campus. Yes, on Suns a better solution is to make sure that /dev/fb is mode 666. Apparently this is the default setting in SunOS 3.4, but not in older versions. With the frame buffer writable, the server doesn't need to be setuid. On machines other than Suns, you have to do something else. The hack I posted has a good chance of working. A better solution would of course be welcome. --- Jef
bob@acornrc.UUCP (Bob Weissman) (04/20/88)
In article <880419085247.195@bl-rtsg>, jef@LBL-RTSG.ARPA (Jef Poskanzer) writes: > Yes, on Suns a better solution is to make sure that /dev/fb is mode 666. > Apparently this is the default setting in SunOS 3.4, but not in older > versions. With the frame buffer writable, the server doesn't need to > be setuid. Our /dev/fb is (and has always been) mode 666, and the X server still refuses to run non-setuid. Any more clues? To paraphrase Freud, "What does Xsun want?" -- Bob Weissman Internet: bob@acornrc.uucp UUCP: ...!{ ames | decwrl | oliveb | apple }!acornrc!bob Arpanet: bob%acornrc.uucp@ames.arc.nasa.gov