[email protected] writes: > on Sun, Jan 28, 2001 at 02:12:44AM -0800, Terry Carney > ([EMAIL PROTECTED]) wrote: > > On Sat, 27 Jan 2001, Christopher R. Barry wrote: > > > > > Xlib: connection to ":0.0" refused by server > > > Xlib: Client is not authorized to connect to Server > > > Error: Can't open display: :0.0 > > > > > > I guess tonight I finally want to get around to figuring out how to > stop this > > > from happening. What do I do so I can run programs as root? > > > > The following works for me. All on one line in case of wordwrap. > > > > XAUTHORITY=/home/username/.Xauthority;DISPLAY=:0.0;export XAUTHORITY > DISPLAY > > *Don't* do this. > > You're now allowing access to root's X display via an unprivileged > user's file. If that file is compromised, root's X access is > compromised. This includes changing the value of the cookie in the > file. > > Better to merge against a user's file. This allows you to match the > present state of the file, but prevent future values from being applied > to root's X authorization keys. Puts root in stronger control.
I guess I don't understand the difference. If the user's ~/.Xauthority file is compromised, and that user owns the X session, all bets are off. Anything opened as root, and displayed in the user-owned X session, is up for grabs. For example, I log in as a user, then su to root and set my XAUTHORITY and DISPLAY environment variables as shown above. I then pop up an xterm, from the root login, and proceed to log in as root on another system. If X security for the user session is compromised another user could, in theory, capture the key strokes and get the root password as it's typed. How am I protected if, instead, I do an xauth merge? Perhaps I'm missing something about how X works? Then there's the whole issue of someone compromising the file ~user/.Xauthority, which should be a mode 600 file. If they do that you've already got some pretty serious problems and someone watching your X apps running as root seems a minor concern. Come to think of it, if they've compromised your user X-session security they already have your root password because they could watch your keystrokes when you did the "su" in an xterm and typed in the root password. If your concern about security is that strong, and there's nothing necessarily wrong with that, you're best off only using the console to log in as root, or at the very least log in as root and start the X session as root. As always, security is a matter of compromise. There's no absolute security -- ever. There's absolutely no way to have a computer that's impossible to get in to. If I were running a serious multi-user system, with users who may try their hand at cracking I'd take the route of never logging in as root except at the console or starting the X session as root. On the other hand if this were my home system and maybe one or two trusted user accounts. I wouldn't hesitate to set the environment variables as described at the beginning. Gary
