Dan Jacobson writes: > The following message is a courtesy copy of an article > that has been posted to gnu.emacs.bug as well. > > This may be a debian specific problem, hence the CC.
No. You need to understand how access control works in the X server. > > It may be "user lack of understanding". If so, "then beef up the > FAQs". Or maybe I didn't look. Anyways, I solved the problem. I put > xhost local:root #dangerous? else root can't open an emacs window > in ~/.xsession. Anyways, the problem was: > > How do I get emacs to run as root when I do su, in its own X window? > $ su > # emacs > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > emacs: Cannot connect to X server :0.0. > Check the DISPLAY environment variable or use `-d'. > Also use the `xhost' program to verify that it is set to permit > connections from your machine. > # xhost > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > xhost: unable to open display ":0.0" > # suspend > $ xhost local:root > non-network local connections being added to access control list > > OK, that fixed it. But gee, don't you see some silly actions above, > like root doing a local command that doesn't need a DISPLAY to get its > job done being denied, etc. Better be nice to root or he will remove you. Basically, you just need to copy the .Xauthority info for the display in question (from ~joeuser/.Xauthority to ~root/.Xauthority). You can't do this directly, you need to use the xauth program to do this for you. I assume that you use startx to start up the X server. If you instead enable xdm, then you can learn from it (/etc/X11/xdm/* how it uses the .Xauthority mechanism. Read the man page for xauth, and the X man page, section about access control, also the xdm man page. Eventually, it will dawn on you what is going on here. I would highly suggest that you read the book "X User Tools" published by O'Reilly, see especially page 430, Section 19.13 "Extending Access Control to Another User'. Then, after you have digested all of this, you will want to automate the mechanism you have been using manually. Hint - create a new group called "xlocal". Make all of those users that you want to be able to automatically share local access to the X server be members of the "xlocal" group. Next, you need to make your source (the user that started up the X server) user's .Xauthority file be readable by group "xlocal". The only catch here is that anytime xauth is run, it will change the perms on your .Xauthority file back to 600, so you need to change them back to 640 after you have run xauth. There are some other subtle details that need to be taken care of in order to create a clean implementation of the scheme that I have just suggested, you will discover them when something goes wrong! Eg, after you su to root, how does the root user know which user originally started up the X server, since it needs to be able to transfer the access records from that user's .Xauthority file? > > By the way, apt-cache show xbase-clients says > xhost, a very dangerous program that you should never use; > Well, the man page didn't warn me. So I used it. Will my system be > ruined now? > > By the way, on the xhost man page it says > FILES > /etc/X*.hosts > > But like hey, > ls: /etc/X*.hosts: No such file or directory > > So it's a mystery where it wrote whatever it wrote. The X server keeps the xhost specified status in its private data. > > P.S. oh, it probably didn't write anywhere, so I do the writing, in .xsession. > -- > http://jidanni.org/ Taiwan(04)25854780 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Jeff Sheinberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]