ssh: errors accessing shell file from /usr/share when using fish and mosh

[skrat]

Description

I'm using mosh , it's running ssh and doing UDP mumbo jumbo, that's beyond this report. I'm also using fish shell (set in /etc/passwd). Now mosh is running ssh to do its thing. This is where firejail is invoked to run ssh. Somehow it needs to run user's shell in that process, but suddenly the files that need to be loaded from /usr/share/fish are not accessible because of some firejail rules. This results in fish spewing errors locally. I'm not sure what to do about it, what to whitelist, etc.

Related:

mobile-shell/mosh#1262

Steps to Reproduce

Steps to reproduce the behavior

1. do some basic edits in ~/.config/fish/config.fish such as calls to fish_add_path or just add some alias ll=ls -l
2. try connecting with mosh to a remote server (needs to have mosh installed and UDP ports accessible, see https://github.com/mobile-shell/mosh#how-it-works)

Expected behavior

It would just connect, not complaining about unknown functions called in ~/.config/fish/config.fish

Actual behavior

Spews errors because functions are not loaded from /usr/share/fish

Behavior without a profile

What changed calling LC_ALL=C firejail --noprofile /path/to/program in a terminal?

~ $ env LC_ALL=C firejail --noprofile /usr/bin/mosh myserver
Parent pid 3060020, child pid 3060021
Child process initialized in 3.72 ms
Warning: an existing sandbox was detected. /usr/bin/ssh will run without any additional sandboxing features


mosh-client needs a UTF-8 native locale to run.

Unfortunately, the client's environment (LC_ALL=C) specifies
the character set "US-ASCII".

LANG=en_US.UTF-8
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

Parent is shutting down, bye...

Additional context

...

Environment

• Arch linux up to date
• Firejail version 0.9.72

Checklist

• The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
• I can reproduce the issue without custom modifications (e.g. globals.local).
• The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
• The profile (and redirect profile if exists) hasn't already been fixed upstream.
• I have performed a short search for similar issues (to avoid opening a duplicate).
  • I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
• I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

[kmk3]

Basic debugging information is missing; please follow the bug report template:

• https://github.com/netblue30/firejail/issues/new?template=bug_report.md

[skrat]

@kmk3 updated description according to template, left out the last part (logs) as I don't find it relevant

[kmk3]

@skrat on Mar 8:

suddenly the files that need to be loaded from /usr/share/fish are not
accessible because of some firejail rules. This results in fish spewing
errors locally.

@skrat on Mar 8:

left out the last part (logs) as I don't find it relevant

What are the errors?

Do they happen when invoking just ssh with firejail?

Example:

firejail /usr/bin/ssh <server>

@skrat on Mar 8:

~ $ env LC_ALL=C firejail --noprofile /usr/bin/mosh myserver
# [...]

mosh-client needs a UTF-8 native locale to run.

What is the output with LC_ALL=en_US.UTF-8?

[skrat]

@kmk3

The errors are about missing functions (alias and fish_add_path) which are defined in files under /usr/share/fish.

No it does not happen when using ssh (firejailed) directly. So yes, this is probably a mosh thing (there is no profile yet).

Yes it works as expected when I invoke mosh with firejail --noprofile.

[kmk3]

ssh.profile has whitelist-usr-share-common.inc, so the following workaround
might fix the errors:

~/.config/firejail/ssh.local:

whitelist /usr/share/fish

Though I think that ideally this would be fixed in mosh (why does it source
local auto-completion files when connecting to a server?) or maybe in a new
mosh.profile.

[glitsj16]

Spews errors because functions are not loaded from /usr/share/fish

The ssh profile includes whitelist-usr-share-common.inc:

firejail/etc/profile-m-z/ssh.profile

Line 23 in 0c00616

include whitelist-usr-share-common.inc

But that included file doesn't whitelist /usr/share/fish, so you'll need at least that. What happens when you add whitelist /usr/share/fish to ssh.local? You might have to create that file, either in ~/.config/firejail or /etc/firejail.

Also, due to mosh not having a separate firejail profile there might be additional things going awry (include logic or otherwise) that we can't see wihout logs. I can understand that you don't find those relevant, but at least double-check everything on your side if the above doesn't fix things.

[skrat]

Those are not just auto-completion functions, they are fairly core functions that are typically called from user's config.fish such as alias. But this is getting weird, it doesn't make sense to whitelist user's shell specific /usr/share resources in (not yet existing) mosh.profile? How about all the other shells?

[skrat]

Here's what's happening https://asciinema.org/a/4AitlLYB2xuA9qsYdNHoABBbI

~ $ mosh myserver
~/.config/fish/config.fish (line 15): Unknown command: fish_add_path
fish_add_path $HOME/.local/bin
^~~~~~~~~~~~^
from sourcing file ~/.config/fish/config.fish
	called during startup
~/.config/fish/config.fish (line 16): Unknown command: fish_add_path
fish_add_path $HOME/.pub-cache/bin
^~~~~~~~~~~~^
from sourcing file ~/.config/fish/config.fish
	called during startup
~/.config/fish/config.fish (line 17): Unknown command: fish_add_path
fish_add_path $HOME/.ebcli-virtual-env/executables
^~~~~~~~~~~~^
from sourcing file ~/.config/fish/config.fish
	called during startup
~/.config/fish/config.fish (line 24): Unknown command: alias
alias vim=nvim
^~~~^
from sourcing file ~/.config/fish/config.fish
	called during startup


[mosh is exiting.]
~ 4s $

[glitsj16]

FWIW, I actually did create firejail profiles for mosh, mosh-client and mosh-server a long time ago when I was using mosh myself. If there's interest I could recover/dust those of and add them to the project. But that will take some time because I would at least have to re-test everything involved. That being said, basically they are simple redirects for ssh.profile. Not hard to create them yourself.

[skrat]

I think we need to find what exactly is running user's shell (fish in this case) and under what conditions. It seems it's not ssh, then it must be mosh, but why is it getting ssh.profile restrictions? When I whitelist /usr/share/fish in .config/firejail/ssh.local, the errors go away.

[kmk3]

@skrat on Mar 8:

Those are not just auto-completion functions, they are fairly core functions
that are typically called from user's config.fish such as alias.

But why would it (re-)source them locally? Does it re-spawn the user shell?

Presumably these files would already have been sourced by the current shell
locally and the remote shell would be sourcing things on the remote host.

But this is getting weird, it doesn't make sense to whitelist user's shell
specific /usr/share resources in (not yet existing) mosh.profile? How
about all the other shells?

This seems to be a quirk of mosh, so such whitelisting (including any other
shells) would be a workaround for it in mosh.profile.

But ideally we would first understand why it tries to do the sourcing.

It could also be added to whitelist-usr-share-common.inc, but it seems
unnecessary if only a single program would use it.

[kmk3]

@skrat on Mar 8:

but why is it getting ssh.profile restrictions? When I whitelist /usr/share/fish in .config/firejail/ssh.local, the errors go away.

/usr/local/bin usually takes precedence over /usr/bin in $PATH and
/usr/local/bin/ssh points to firejail, so ssh -> /usr/local/bin/ssh ->
firejail /usr/bin/ssh (see firecfg(1)).

[glitsj16]

But this is getting weird, it doesn't make sense to whitelist user's shell specific /usr/share resources in (not yet existing) mosh.profile? How about all the other shells?

Here are my mosh profiles:

• download the files
• put them in your ~/.config/firejail
• create symlinks for them under /usr/local/bin (cfr. what firecfg does) or test them from command line using full paths

[glitsj16]

I actually don't see anything that 'weird' here. The ssh profile that's being called simply doesn't whitelist /usr/share/fish. A local override can fix that without doing anything else IMO. But let's wait and see what happens when @skrat uses these referenced mosh profiles.

[skrat]

Nothing happens with those profile, same error. There's still no explanation why locally spawned user shell is getting ssh.profile restrictions.

[eminence]

I know nothing about fish or about firejail, but when you mosh into a remote server, the mosh-server process is initially launched by the sshd, and then mosh-server will to the usual fork/daemonize dance and then spawn the user's default shell as a subprocess

[glitsj16]

@skrat

When I whitelist /usr/share/fish in .config/firejail/ssh.local, the errors go away.

Good.

Nothing happens with those profile, same error.

Seems to contradict the above. If whitelist /usr/share/fish fixed the errors, it will/should do the same, whether you've placed that option in ssh.local or in mosh.profile.

There's still no explanation why locally spawned user shell is getting ssh.profile restrictions.

But there is an explanation:

(1) According to your opening post you've set your user to use fish shell in /etc/passwd.
(2) You're using firejail (probably also firecfg for desktop intehration).
(2) See #5721 (comment).

Please, I'm not intending to dispute what you're seeing, nor am I trying to be snug here. Based on what you've showed in this thread it all seems pretty straightforward. And fixable.