envfs doesnt seem to work in fish shell while working in bash

[Alper-Celik]

here is a demonstration : https://asciinema.org/a/qRPllYfj9MJg2wE5CWtEQ6JNm

[Alper-Celik]

it also doesnt work with /usr/bin/fastfetch

[s1syph0s]

I'm having a similar problem.. I am also using fish shell, and I can't call my packages using either /bin or /usr/bin prefix.. If this is a bug, I would also be happy to try to solve this!

[s1syph0s]

So I tried several shells, and envfs is working on bash and zsh, but not on fish and nushell. I'm trying to create a fix for this, but I might need some pointers on why it works on those shells but not the others.. My guess is that fish and nushell are not compatible with bash and zsh, but I didn't find any bash and zsh specific commands in the code.

[fzakaria]

I thin I found the issue.

Here is how commands are executed in fish: https://github.com/fish-shell/fish-shell/blob/master/src/path.rs#L286C1-L293C10

        let Ok(md) = std::fs::metadata(OsStr::from_bytes(&narrow)) else {
            return Err(errno());
        };
        if md.is_file() {
            Ok(())
        } else {
            Err(Errno(EACCES))
        }

metadata is explicitly disabled unless ENVFS_RESOLVE_ALWAYS is set to true (I'm not sure why this decision was made)

Here is proof:

> /bin/atuin --help
/bin/atuin: command not found

> ENVFS_RESOLVE_ALWAYS=1 fish
> /bin/atuin --help
atuin 18.4.0
Ellie Huxtable <[email protected]>
Magical shell history

Usage:
  atuin <COMMAND>

[fzakaria]

@Mic92 should ENVFS_RESOLVE_ALWAYS be always true? I'm not sure why it's restricted here for stat and ls ;

@s1syph0s we can maybe check if the shell is fish (arg[0] or $SHELL) and skip the check for ENVFS_RESOLVE_ALWAYS maybe?

[s1syph0s]

@fzakaria Interesting find! I was also inspecting the fish source code because the execve syscall was never called when using fish. I didn't think that it was the metadata!

we can maybe check if the shell is fish (arg[0] or $SHELL) and skip the check for ENVFS_RESOLVE_ALWAYS maybe?

I think checking the arg[0] is better than $SHELL, because at least in my system, the $SHELL variable still points to bash (I need to confirm this again later at home).

[s1syph0s]

Looking at this, we might be able to fix this for fish without skipping the check to ENVFS_RESOLVE_ALWAYS. To my current knowledge, fish doesn't directly execute execve syscall like *sh. Instead, it calls access and faccessat first to check if the file really exist (CMIIW). I'll try to whitelist both syscalls later at home and look at the result.

[Mic92]

I thin I found the issue.

Here is how commands are executed in fish: https://github.com/fish-shell/fish-shell/blob/master/src/path.rs#L286C1-L293C10

        let Ok(md) = std::fs::metadata(OsStr::from_bytes(&narrow)) else {
            return Err(errno());
        };
        if md.is_file() {
            Ok(())
        } else {
            Err(Errno(EACCES))
        }

metadata is explicitly disabled unless ENVFS_RESOLVE_ALWAYS is set to true (I'm not sure why this decision was made)

Here is proof:

/bin/atuin --help /bin/atuin: command not found

ENVFS_RESOLVE_ALWAYS=1 fish /bin/atuin --help atuin 18.4.0 Ellie Huxtable [email protected] Magical shell history

Usage: atuin <COMMAND>

There are programs that first check for absolute paths to executables and than run a child program without any environment set (i.e. podman does that). This is why the syscall filter is in place.

[fzakaria]

@Mic92 not sure i understand; The syscall filter is to stop them from working?

Why not just let all syscalls through. (Sorry I didn't get your explanation)

How do you recommend me fix this? I can put up a PR if we have consensus.

[fzakaria]

@Mic92 every issue i found explaining the syscall filters seem related to podman; This amazing tool has applied filters that seem to be causing issues for X applications to make 1 (podman) work.

Why not flip the expectation and have the filters only applied in some conditional is set; which podman can do? (The environment variable can be a BLACK_LIST of syscalls for instance)

[Mic92]

@Mic92 every issue i found explaining the syscall filters seem related to podman; This amazing tool has applied filters that seem to be causing issues for X applications to make 1 (podman) work.

Why not flip the expectation and have the filters only applied in some conditional is set; which podman can do? (The environment variable can be a BLACK_LIST of syscalls for instance)

I think GNOME also had some issue, but I don't remember the details.