[BUG] Docker mount namespace procfs /proc/PID/root [fd error]: Could not retrieve current directory
danielzgtg opened this issue · 2 comments
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
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.
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.