Re: emacs to run as root from su, in its own X window?
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 debian-emacsen-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Jeff Sheinberg <jeffsh@erols.com>
--
To UNSUBSCRIBE, email to debian-emacsen-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: