[bug] 2 dots (../) relative path at the beginning of path

[Mark-Joy]

Have you checked borgbackup docs, FAQ, and open Github issues?

Yes, I have read some of them, not sure if I missed something

Is this a BUG / ISSUE report or a QUESTION?

Seems to be a bug

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

1.2.0b3

Operating system (distribution) and version.

Android Pie

Hardware / network configuration, and filesystems used.

How much data is handled by borg?

Full borg commandline that lead to the problem (leave away excludes and passwords)

borg create --show-version --info --progress --stats --list --compression=lz4 ::etc-{now} ../usr/etc

Describe the problem you're observing.

After backup was created, the 2 dots part at the beginning of the path was removed.

$ borg list --show-version --info --progress --sort-by=name --format='{path} {user} {size}{NL}' ::etc-2021-08-25T02:51:07
borgbackup version 1.2.0b3
usr/etc u0_a485 0
usr/etc/xattr.conf u0_a485 681
...

Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.

Include any warning/errors/backtraces from the system logs

[ThomasWaldmann]

Guess that's expected, borg removes leading /(and guess also leading ../).

Can you compare it with what tar does?

[ThomasWaldmann]

Note: removal of ../ path prefixes is done in borg.helpers.fs.make_path_safe.

[Mark-Joy]

I just did some tests. Borg also removes leading ./ But why?
From document, I thought borg allows using relative path as ./ and ../. It would be a useful feature, for example, I can be at $HOME dir and extract everything without changing dir.
I actually managed to use it with --paths-from-stdin or --paths-from-command

$ printf "../usr/etc ./../usr/etc/xattr.conf" | borg create --show-version --info --progress --stats --list --compression=lz4 --paths-delimiter=" " --paths-from-stdin ::etc-{now}

Result:

$ borg list --show-version --info --progress --sort-by=name --format='{path} {user} {size}{NL}' ::etc-2021-08-27T02:14:52
borgbackup version 1.2.0b3
usr/etc u0_a485 0
./../usr/etc/xattr.conf u0_a485 681

As above result, leading ../ was removed but not ./../ (they have the same meaning though). And it only works with --paths-from-stdin or paths-from-command
While we are at it, I shall also mention that:

1. With --paths-from-stdin or command, folder path ../usr/etc was added but borg did not include any files/folders below it. I had to manually add a file path for testing: ./../etc/xattr.conf
2. --progress option seems to cause some messed up text.
   

[ThomasWaldmann]

Guess for --paths-from-*, it is expected that you give ALL fs paths you want borg to process (basically replacing borg's internal recursion with an external file list / process).

If you want borg to do the recursion, you should invoke borg the usual way, not with --paths-from-*.

[ThomasWaldmann]

You should never mix --listand --progress, you can't have both writing to your screen and get clean output.

[ThomasWaldmann]

borg.helpers.fs.make_path_safe lacks good documentation about the "why".

if you have time, you could dig into git history and try to find out what the precise problem is for which it exists.

maybe one thing is that if you are in /somedir and extract a borg archive, the expectation is that it is extracted in there.
if it would extract stuff starting with ../, it would also extract stuff outside of there.

[Mark-Joy]

Thank you very much for details explanation.
Can it be that borg save the path as it was provided and only do make_path_safe when extracting/mounting (default behaviour)?
By that, it can support another option/switch to really use the provided-path(absolute path or ../ double-dots relative path) when extracting. Now user has the responsibility since the option has to be written explicitly.

Preserving these when doing borg mount is definitely problematic, see #7099. It seems like leading ../ is already stripped but ./ is not.

[pgerber]

Can you compare it with what tar does?

In tar allowing ../ would is considered a security issue. Just one example would be https://security-tracker.debian.org/tracker/CVE-2007-4131.

[ThomasWaldmann]

See also the discussion in #7108.

[ThomasWaldmann]

Closing this as "works as expected".

Leading slashes /, dot (./) and dotdot (../) and also inner dot and dotdot are removed during a normalisation step.

Extracting such stuff could be a security issue, trying to build a FUSE fs from such is also problematic.