RPC error on socket when opening a privileged shell while preserving the environment

[zilbuz]

If I try to open a root elvish shell while preserving the environement (with sudo -s -E for instance), elvish print an error indicating that it cannot connect to the daemon.

~> sudo -s -E   # Same with sudo -E /usr/bin/elvish
Cannot connect to daemon: unexpected RPC error on socket /tmp/elvish-0/sock: timeout
Daemon-related functions will likely not work.
Failed to initialize command history; disabled.
~#

If I don't preserve the environment, the shell loads just fine:

~> sudo -s  # Same with sudo /usr/bin/elvish
/home/zilbuz#

The culprit seems to be the HOME environment variable. If I unset it before launching elvish as root, then I can use -E:

~> unset-env HOME
~> sudo -s -E  # Same with sudo -E /usr/bin/elvish
/home/zilbuz#

As a workaround, I observed that I can launch elvish using the same socket than my regular user:

~> sudo -E /usr/bin/elvish -sock /tmp/elvish-1000/sock
~#

What should I do?

• Should I not preserve the environment and copy my rc.elv in the root home directory?
• Should I preserve the environment except for HOME?
• Should I explicitly use the user socket even with a root session?
• Or is it something that should be fixed directly in elvish? (And what can I do to help?)
• Or maybe I just shouldn't use elvish as root :)

[xiaq]

Interesting, I should look into this later. I wonder how tmux and other programs that have servers handle this.

[chengxuncc]

Is it fixed now? It bother me so much because I can't use history⬆ with root.

/mnt> sudo -s
Cannot connect to daemon: unexpected RPC error on socket /tmp/elvish-0/sock: timeout
Daemon-related functions will likely not work.
Failed to initialize command history; disabled.
/mnt#
history offline
history offline
/mnt#

[chengxuncc]

~> elvish -version
v0.14.0
~> sudo -s
Cannot connect to daemon: unexpected RPC error on socket /tmp/elvish-0/sock: timeout
Daemon-related functions will likely not work.
~> exit
~> panic: runtime error: invalid memory address or nil pointer dereference     
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x77fe81]

goroutine 33 [running]:
github.com/elves/elvish/pkg/daemon.Serve.func1(0xc0001400c0, 0xc000140120, 0x7f)
	github.com/elves/elvish@/pkg/daemon/serve.go:47 +0x171
created by github.com/elves/elvish/pkg/daemon.Serve
	github.com/elves/elvish@/pkg/daemon/serve.go:36 +0x3f7

[rautesamtr]

@chengxuncc sudo -s works fine for me on master As @zilbuz suggests for sudo -s -E your can use: sudo -E -u root /usr/bin/elvish -sock $E:XDG_RUNTIME_DIR/elvish/sock Note that on master sock has been moved from tmp to XDG_RUNTIME_DIR

edit: it also looks like it is not using the existing user sock by design since it isn't consider it a secure/exclusive dir: https://github.com/elves/elvish/blob/master/pkg/shell/paths_unix.go#L54

[chengxuncc]

I will wait for updating, no history with root can be fine, Thanks @raetiacorvus.

[krader1961]

This issue is another example for why the Elvish daemon should be eliminated. See also issue #1191 and #126.

[krader1961]

This issue appears to be obsolete. I can execute sudo -s -E /opt/bin/elvish on macOS without error. The HOME env var value is my, not the root, home dir. The command history of the sudo session is private to that session. That is, it is not propagated to the pre-sudo history. This seems perfectly cromulent to me.

P.S., Note that pressing [Up-Arrow] after the sudo results in "error: end of history" because the sudo shell does not have access to the history of the user who ran sudo. This also seems reasonable to me.