I'm setting up a new system and need to grant the root user authority to access the nonroot user's X display in order to run GUI utilities. I used the xhost command for this as follows, but mistakenly leaving off the colon suffix seems to have allowed access to the remote server lb.usemaxserver.de...

  nonroot@host2:~  xhost -
access control enabled, only authorized clients can connect
  nonroot@host2:~  xhost local
local being added to access control list
  nonroot@host2:~  xhost
access control enabled, only authorized clients can connect
INET:lb.usemaxserver.de
INET:localhost

I've used the following to remove it...

  nonroot@host2:~  xhost -INET:lb.usemaxserver.de
lb.usemaxserver.de being removed from access control list

Am I interpreting this correctly?

If so, how did lb.usemaxserver.de setup something so that local links to that addess?

Does this require there to be some malicious configuration or software already on my system? If so, any suggestions for where to look?

  • A better way is to use MIT-auth cookies. Figure out where the X server you start gets his cookies from, and give this cookie to root, with xauth or other methods. – dirkt Sep 28 at 6:12
up vote 2 down vote accepted

I'm setting up a new system and need to grant the root user authority to access the nonroot user's X display in order to run GUI utilities.

It sounds like you want xhost +si:localuser:root. (This is not available on all X implementations. man Xsecurity also says that it is not entirely effective on some implementations. But it seems better than +local:)

Also, your X server was probably not directly accessible from the network anyway. E.g. see How can I connect to a remote X server _without_ ssh?

I used the xhost command for this as follows, but ... seems to have allowed access to the remote server lb.usemaxserver.de

xhost +local looks up the hostname local, so it depends what you have in your DNS search path etc.

$ xhost +local
xhost:  bad hostname "local"
$ dig local
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
...

It sounds like your system resolves local, to a couple of different hosts. Compare:

$ xhost +smtp.gmail.com
smtp.gmail.com being added to access control list
$ xhost
access control enabled, only authorized clients can connect
INET6:wr-in-x6d.1e100.net
INET:wr-in-f108.1e100.net
INET:wr-in-f109.1e100.net
SI:localuser:alan
$ dig smtp.gmail.com
...
smtp.gmail.com.     104 IN  CNAME   gmail-smtp-msa.l.google.com.
gmail-smtp-msa.l.google.com. 104 IN A   108.177.15.108
gmail-smtp-msa.l.google.com. 104 IN A   108.177.15.109
...
$ dig AAAA smtp.gmail.com
smtp.gmail.com.     170 IN  CNAME   gmail-smtp-msa.l.google.com.
gmail-smtp-msa.l.google.com. 271 IN AAAA    2a00:1450:400c:c0c::6c
$ dig -x 2a00:1450:400c:c0c::6c
c.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.c.0.c.0.0.4.0.5.4.1.0.0.a.2.ip6.arpa. 300 IN PTR wr-in-x6c.1e100.net.
  • 1
    This works. Thanks. I've also determined that the "local = lb.usemaxserver.de" was due to entries in /etc/hosts. It's an antiX 17.1 distro that includes adblocking by zeroing out hundreds of addresses in that file and there were some erroneous entries. – DocSalvager Sep 28 at 8:07
  • @DocSalvager that's hilarious, thank you for the followup :-D. – sourcejedi Sep 28 at 10:25

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.