[BUG] Docker mount namespace procfs /proc/PID/root [fd error]: Could not retrieve current directory

[danielzgtg]

Checks

• I have read the troubleshooting section and still think this is a bug.

Describe the bug you encountered:

fd doesn't work in /proc/PID/root when that directory is in another mount namespace. My use case is using the host's fd to inspect Docker containers when they don't provide a fd binary.

$ # Setup a mount-namespaced process, with current UID to ensure it's accessible later
$ docker run -it --rm ubuntu:lunar setpriv --reuid $UID --regid $UID --clear-groups sleep 999999999

$ # In another terminal
$ cd /proc/`pidof sleep`/root
$ fd
[fd error]: Could not retrieve current directory (has it been deleted?).

Describe what you expected to happen:

It should print the directories like with a PID whose process's /proc/PID/ns/mnt is the root or fd's namespace. Both find and exa are able to.

What version of fd are you using?

fd 10.1.0

Which operating system / distribution are you on?

$ uname -srm
Linux 6.8.8-surface-1 x86_64
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 23.10
Release:        23.10
Codename:       mantic

[tavianator]

This is a case where getcwd() fails to get the absolute path to the current directory. You can also get into this situation by calling chroot() without chdir().

$ strace --trace=getcwd fd
getcwd("(unreachable)/", 1024)          = 15

I think we should fix fd to not require the absolute path to the cwd, but I'm not sure how hard that would be. As a band-aid for this particular case, we could try to use the environment variable PWD as a fallback if getcwd() fails.

[danielzgtg]

Me using bash, your solution should work.

However, a slightly academic case is non-POSIX compliant shells like pwsh that leave PWD stale. eza and find still work without getcwd() and $PWD, If it comes to that case, we could just gracefully degrade and skip the ensure_current_directory_exists and strip_current_dir stuff.