bubblewrap icon indicating copy to clipboard operation
bubblewrap copied to clipboard

--bind, --chdir and relative destination paths

Open q3cpma opened this issue 3 years ago • 2 comments

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

q3cpma avatar Apr 10 '22 11:04 q3cpma

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.

smcv avatar Apr 11 '22 10:04 smcv

Maybe a documentation fix saying that all bindings with relative DESTs are done in /? On that subject, manpage is missing --share-net.

q3cpma avatar Apr 11 '22 15:04 q3cpma