--bind, --chdir and relative destination paths
Hello, I was a bit suprised by the following behaviour and I wondered if this was a WONTFIX or if my surprise was legitimate and improvable.
If I use --dir "$PWD" --chdir "$PWD" --ro-bind aaa aaa, I expect aaa to be bound in "$PWD", but it's bound in /. I could understand not wanting to complicate things by mixing the CWD and paths, but who knows.
Test case:
$ cd
$ touch aaa
$ bwrap --ro-bind /bin /bin --ro-bind /usr/bin /usr/bin --ro-bind /usr/lib /usr/lib --ro-bind /lib64 /lib64 --dir "$PWD" --chdir "$PWD" --ro-bind aaa aaa sh -c 'ls -l; ls -l /'
total 0
total 16
-rw-r--r-- 1 1000 1000 0 Apr 10 11:15 aaa
drwxr-xr-x 2 0 0 4096 Apr 8 20:56 bin
drwxr-xr-x 3 1000 1000 60 Apr 10 11:16 home
drwxr-xr-x 6 0 0 8192 Apr 8 20:56 lib64
drwx------ 4 1000 1000 80 Apr 10 11:16 usr
If I use --dir "$PWD" --chdir "$PWD" --ro-bind aaa aaa, I expect aaa to be bound in "$PWD", but it's bound in /. I could understand not wanting to complicate things by mixing the CWD and paths, but who knows.
Your interpretation is reasonable, but I'd be concerned that if we changed from the current behaviour to your interpretation, we'd be breaking compatibility with users or scripts that are (intentionally or unintentionally) relying on the current behaviour.
Honestly, I'd recommend always passing absolute paths to bwrap, either explicitly or in the form "$(pwd)/foo". Rewriting the filesystem layout is always going to give relative paths rather strange behaviour.
Maybe a documentation fix saying that all bindings with relative DESTs are done in /? On that subject, manpage is missing --share-net.