symlink handling in OCI containers

[drahnr]

In the context of oci image archive routines, symbolic links pointing to absolute-within-the-to-be-hydrated-root-filesystem are encountered, i.e.:

python -> /root/.pyenv/3.12/python

Now when tar-rs encounters these, ::std::os::unix::fs::symlink(original, link) is called without any further adjustment of link. Now for the OCI container execution this is fine, since the root path / is mapped to the base of the tar archive and hence isn't an issue.
However, if the hydrated root filesystem is traversed manually or executed without unix namespace isolation, we end up with a rootfs pointing to different locations.

I see a few possible solutions:

• declare it as a non-use and be explicit about symlink handling
• make these symlinks relative, retaining the semantics, similar to entry: fix unpacking relative hardlinks #113
• conditionally prefix it with the dst directory
• add options to replace symlink with copies or hardlinks

Note that it's a bit more complicated than #113 , since to the best of my knowledge, there is no unpacks before relation for symlinks and its target as there is for hardlinks and hence fs::canonicalize will fail (related: 7843d6a )

From a quick scout, there are multiple issues related:

• Extracting archive with symlink fails on Windows #268
• entry: chase outgoing links #132
• tar-rs fails to decompress some ostree archives #367

From the issues I read so far, I see two competing use-cases:

• symlinks must always point inside the tar
• symlinks can point to absolute paths /
  • since the context will remap / to the unpacked tar (the OCI use-case)
  • it's a feature

Extrapolating, it might make sense to allow for a-hooks-like API to modify paths pre-unpacking OR a unpacker API similar to #355
Both are somewhat invasive.

Consider the above a preliminary investigation.