[GH-ISSUE #5721] ssh: errors accessing shell file from /usr/share when using fish and mosh

gitea-mirror commented

2026-05-05 09:42:53 -06:00

Owner

Originally created by @skrat on GitHub (Mar 8, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5721

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.

Steps to Reproduce

Steps to reproduce the behavior

do some basic edits in ~/.config/fish/config.fish such as calls to fish_add_path or just add some alias ll=ls -l
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)

Originally created by @skrat on GitHub (Mar 8, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5721  ### Description I'm using [mosh ](https://github.com/mobile-shell/) , 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: https://github.com/mobile-shell/mosh/issues/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  - [x] 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](https://github.com/netblue30/firejail/tree/master/etc). - [x] 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)

gitea-mirror commented

2026-05-05 09:42:55 -06:00

Author

Owner

@kmk3 commented on GitHub (Mar 8, 2023):

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

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

@kmk3 commented on GitHub (Mar 8, 2023): Basic debugging information is missing; please follow the bug report template: * <https://github.com/netblue30/firejail/issues/new?template=bug_report.md>

gitea-mirror commented

2026-05-05 09:42:56 -06:00

Author

Owner

@skrat commented on GitHub (Mar 8, 2023):

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

@skrat commented on GitHub (Mar 8, 2023): @kmk3 updated description according to template, left out the last part (logs) as I don't find it relevant

gitea-mirror commented

2026-05-05 09:42:57 -06:00

Author

Owner

@kmk3 commented on GitHub (Mar 8, 2023):

@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?

@kmk3 commented on GitHub (Mar 8, 2023): @skrat [on Mar 8](https://github.com/netblue30/firejail/issues/5721#issue-1615780352): > 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](https://github.com/netblue30/firejail/issues/5721#issuecomment-1460733086): > 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: ```sh firejail /usr/bin/ssh <server> ``` @skrat [on Mar 8](https://github.com/netblue30/firejail/issues/5721#issue-1615780352): > ``` > ~ $ 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`?

gitea-mirror commented

2026-05-05 09:42:58 -06:00

Author

Owner

@skrat commented on GitHub (Mar 8, 2023):

@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.

@skrat commented on GitHub (Mar 8, 2023): @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`.

gitea-mirror commented

2026-05-05 09:42:59 -06:00

Author

Owner

@kmk3 commented on GitHub (Mar 8, 2023):

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.

@kmk3 commented on GitHub (Mar 8, 2023): 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.

gitea-mirror commented

2026-05-05 09:43:00 -06:00

Author

Owner

@ghost commented on GitHub (Mar 8, 2023):

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

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

0c00616634/etc/profile-m-z/ssh.profile (L23)

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.

@ghost commented on GitHub (Mar 8, 2023): > Spews errors because functions are not loaded from /usr/share/fish The ssh profile includes `whitelist-usr-share-common.inc`: https://github.com/netblue30/firejail/blob/0c006166347ceee63c7e5e944d58f10ee888d6d2/etc/profile-m-z/ssh.profile#L23 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.

gitea-mirror commented

2026-05-05 09:43:01 -06:00

Author

Owner

@skrat commented on GitHub (Mar 8, 2023):

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 commented on GitHub (Mar 8, 2023): 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?

gitea-mirror commented

2026-05-05 09:43:02 -06:00

Author

Owner

@skrat commented on GitHub (Mar 8, 2023):

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 $

@skrat commented on GitHub (Mar 8, 2023): 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 $ ```

gitea-mirror commented

2026-05-05 09:43:03 -06:00

Author

Owner

@ghost commented on GitHub (Mar 8, 2023):

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.

@ghost commented on GitHub (Mar 8, 2023): 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.

gitea-mirror commented

2026-05-05 09:43:04 -06:00

Author

Owner

@skrat commented on GitHub (Mar 8, 2023):

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.

@skrat commented on GitHub (Mar 8, 2023): 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.

gitea-mirror commented

2026-05-05 09:43:05 -06:00

Author

Owner

@kmk3 commented on GitHub (Mar 8, 2023):

@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 commented on GitHub (Mar 8, 2023): @skrat [on Mar 8](https://github.com/netblue30/firejail/issues/5721#issuecomment-1460766037): > 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.

gitea-mirror commented

2026-05-05 09:43:05 -06:00

Author

Owner

@kmk3 commented on GitHub (Mar 8, 2023):

@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)).

@kmk3 commented on GitHub (Mar 8, 2023): @skrat [on Mar 8](https://github.com/netblue30/firejail/issues/5721#issuecomment-1460800057): > 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)`).

gitea-mirror commented

2026-05-05 09:43:06 -06:00

Author

Owner

@ghost commented on GitHub (Mar 8, 2023):

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

@ghost commented on GitHub (Mar 8, 2023): > 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](https://gist.github.com/glitsj16/1ed3748b54e2e52f368bfe8387ab750f): - 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

gitea-mirror commented

2026-05-05 09:43:07 -06:00

Author

Owner

@ghost commented on GitHub (Mar 8, 2023):

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.

@ghost commented on GitHub (Mar 8, 2023): 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.

gitea-mirror commented

2026-05-05 09:43:07 -06:00

Author

Owner

@skrat commented on GitHub (Mar 8, 2023):

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

@skrat commented on GitHub (Mar 8, 2023): Nothing happens with those profile, same error. There's still no explanation why locally spawned user shell is getting ssh.profile restrictions.

gitea-mirror commented

2026-05-05 09:43:08 -06:00

Author

Owner

@eminence commented on GitHub (Mar 8, 2023):

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

@eminence commented on GitHub (Mar 8, 2023): 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

gitea-mirror commented

2026-05-05 09:43:08 -06:00

Author

Owner

@ghost commented on GitHub (Mar 8, 2023):

@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 https://github.com/netblue30/firejail/issues/5721#issuecomment-1460805718.

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.

@ghost commented on GitHub (Mar 8, 2023): @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 https://github.com/netblue30/firejail/issues/5721#issuecomment-1460805718. 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.

Rows
Columns

[GH-ISSUE #5721] ssh: errors accessing shell file from /usr/share when using fish and mosh #3073

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist