"File at" syscalls with the AT_FDCWD fd don't work correctly in Shadow #1495
Description
Updated the issue title to match the bug. This bug causes programs that use these "file at" syscalls to not work correctly (for example 'rm' and 'mv').
Original issue:
The programs /usr/bin/rm and /usr/bin/mv don't run correctly in Shadow. They aren't able to see files in the current working directory.
general:
stop_time: 1 min
network:
graph:
type: 1_gbit_switch
hosts:
myhost:
processes:
- path: /usr/bin/touch
args: myfile
start_time: 1
- path: /usr/bin/ls
args: '-l'
start_time: 2
- path: /usr/bin/rm
args: myfile
start_time: 3total 8
-rw-rw-r-- 1 user user 0 Jul 1 2021 myfile
-rw-rw-r-- 1 user user 0 Jul 1 2021 myhost.ls.1001.shimlog
-rw-r--r-- 1 user user 0 Jul 1 2021 myhost.ls.1001.stderr
-rw-r--r-- 1 user user 0 Jul 1 2021 myhost.ls.1001.stdout
-rw-rw-r-- 1 user user 1 Jul 1 2021 myhost.touch.1000.exitcode
-rw-rw-r-- 1 user user 0 Jul 1 2021 myhost.touch.1000.shimlog
-rw-r--r-- 1 user user 64 Jul 1 2021 myhost.touch.1000.stderr
-rw-r--r-- 1 user user 0 Jul 1 2021 myhost.touch.1000.stdout
/usr/bin/rm: cannot remove 'myfile': No such file or directory
The file definitely exists in the hosts directory, and we can see it when we run /usr/bin/ls -l in Shadow, but rm and mv say it doesn't exist.
These programs are small enough that they should be fairly easy to debug with strace.