Set `xhost +` to run automatically on startup/login?

English Install/Boot/Login
21

Yeah, systemd-run was one of the key words I used when I bookmarked your post in that topic for myself for later,
but honestly I’m still not sure I’m following you completely…

Thanks for telling me about systemctl --user show-environment!

The fish equivalent for that line is:

export (systemctl --user show-environment  | command grep '^XAUTHORITY=')

(
fish just drops the $ from $(),
and I know I should make sure to use the default grep to avoid any weird alias tweaks I might do to it.
)

But yeah, you’re saying I should use that line in my “fishrc” instead of using xhost +?

Like, what I currently have in my fishrc
(in the section that runs when the host is the opensuse computer)
is this:

	if test -z "$SSH_CLIENT" # -z        (String length is zero)
		xhost +LOCAL: &>/dev/null
	end

(
So that runs on the opensuse computer when it’s not over ssh
– I’m not sure using "$SSH_CLIENT" like that is the “correct” way to do it,
but that’s just what I picked up years ago, no idea where.
)

But you’re saying I should try instead this?:

	if test -n "$SSH_CLIENT" # -n         (String length is non-zero)
		export (systemctl --user show-environment  | command grep '^XAUTHORITY=')
	end

(So it runs on the opensuse computer only when it is over ssh.)

I just tested it and…
yup, it works!

And that certainly does seem superior
in at least that:

  • it doesn’t require xhost to be installed,
  • it’s only being run for ssh when needed,
    rather than for every non-ssh shell

And I suspect it’s likely better for other reasons I don’t understand yet.

Thank you!

(
Technically it’s “config.fish” not “fishrc”
but it just occurred to me I may as well do:
ln -s ~/.config/fish/config.fish ~/.fishrc
)

22

Right, I just meant viewing the file to check what the defaults are,
not editing it.

Although that just made me realize I don’t actually know for sure:

What happens if you created a new file like eg
/etc/foo.config
not knowing that there was already a file like eg
/usr/etc/foo.config
?

Is there a standard behavior where the one under /etc/ takes precedence over the one in /usr/etc/ or something?
(Or is there at least generally supposed to be a standard behavior?)

Or does it just kinda depend on the specific program or whatever?

23

No. It is entirely up to the individual application.

https://en.opensuse.org/openSUSE:Packaging_UsrEtc

1 Like
24

Exporting XAUTHORITY is functionally identical to xhost +si:localuser:your-user-name. You opened connection from any program on the local host running as any user. Whether it can be considered as potential threat is entirely up to you. Others often want to open GUI program from a system service, and xhost +LOCAL: is the most straightforward way to allow it (except to run modern programs X server connection alone is often not enough).

1 Like
25

Well, I was using the more generic xhost +LOCAL: just cuz I wasn’t sure yet about the syntax for anything more specific (xhost +si:localuser:$USER)
and I figured I’d worry about narrowing that down after I got a solution that was working for me at all.

But you’re saying that

	if test -z "$SSH_CLIENT" # not ssh # -z        (String length is zero)
		xhost +si:localuser:$USER &>/dev/null
	end

has no advantage in how “secure” it is
(ie vs export (systemctl --user show-environment | command grep '^XAUTHORITY='))
cuz it’s “functionally identical”?
(
I know $XAUTHORITY and ~/.Xauthority both literally contain the string MIT-MAGIC-COOKIE mixed in with the binary gibberish,
so I expect I won’t be able to understand any details beyond “functionally identical”,
since it’s apparently officially magic :wink:
)

So for

	if test -n "$SSH_CLIENT" # yes ssh # -n         (String length is non-zero)
		export (systemctl --user show-environment  | command grep '^XAUTHORITY=')
	end

the only advantages of it are:

  • it’s only run in an ssh session when it might needed
  • and it’s one less dependency
    (if I’m remembering correctly, xhost did not come pre-installed)

right?