Incorrect absolute symbolic links upon extraction
A free file archiver for extremely high compression
Brought to you by:
ipavlov
When extracting an archive/image using -snld
and -o
switches, the absolute symlinks are prefixed with the output directory.
In practice, if we extract a root filesystem from an image file, links are damaged in a chroot
-ed environment. The logic is also ambiguous as we are explicitly allowing insecure symlinks with the -snld
switch, and it doesn't rewrite insecure relative links.
7-Zip 23.01 (arm64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
64-bit arm_v:8 locale=C.UTF-8 Threads:8 OPEN_MAX:1048576
mkdir -p rootfs/a rootfs/b
touch rootfs/a/1
ln -s /a/1 rootfs/b/2
ln -s ../a/1 rootfs/b/3
(cd rootfs && 7z -snl a ../rootfs.tar .)
7z -otest -snld x rootfs.tar
The links are stored correctly, as we can see in the debug output:
# 7z -slt l rootfs.tar
7-Zip 23.01 (arm64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
64-bit arm_v:8 locale=C.UTF-8 Threads:8 OPEN_MAX:1048576
Scanning the drive for archives:
1 file, 3584 bytes (4 KiB)
Listing archive: rootfs.tar
--
Path = rootfs.tar
Type = tar
Physical Size = 3584
Headers Size = 3584
Code Page = UTF-8
Characteristics = GNU ASCII
----------
Path = a
Folder = +
Size = 0
Packed Size = 0
Modified = 2024-07-31 12:34:13
Created =
Accessed =
Mode = drwxr-xr-x
User =
Group =
User ID = 0
Group ID = 0
Symbolic Link =
Hard Link =
Characteristics = 5 GNU ASCII
Comment =
Device Major =
Device Minor =
Path = a/1
Folder = -
Size = 0
Packed Size = 0
Modified = 2024-07-31 12:34:13
Created =
Accessed =
Mode = -rw-r--r--
User =
Group =
User ID = 0
Group ID = 0
Symbolic Link =
Hard Link =
Characteristics = 0 GNU ASCII
Comment =
Device Major =
Device Minor =
Path = b
Folder = +
Size = 0
Packed Size = 0
Modified = 2024-07-31 12:34:13
Created =
Accessed =
Mode = drwxr-xr-x
User =
Group =
User ID = 0
Group ID = 0
Symbolic Link =
Hard Link =
Characteristics = 5 GNU ASCII
Comment =
Device Major =
Device Minor =
Path = b/2
Folder = -
Size = 4
Packed Size = 0
Modified = 2024-07-31 12:34:13
Created =
Accessed =
Mode = lrwxrwxrwx
User =
Group =
User ID = 0
Group ID = 0
Symbolic Link = /a/1
Hard Link =
Characteristics = 2 GNU ASCII
Comment =
Device Major =
Device Minor =
Path = b/3
Folder = -
Size = 6
Packed Size = 0
Modified = 2024-07-31 12:34:13
Created =
Accessed =
Mode = lrwxrwxrwx
User =
Group =
User ID = 0
Group ID = 0
Symbolic Link = ../a/1
Hard Link =
Characteristics = 2 GNU ASCII
Comment =
Device Major =
Device Minor =
But in the extracted folder, the absolute link (test/b/2
) is being rewritten:
# ls -la test/b
total 8
drwxr-xr-x 2 root root 4096 Jul 31 12:34 .
drwxr-xr-x 4 root root 4096 Jul 31 12:39 ..
lrwxrwxrwx 1 root root 13 Jul 31 12:39 2 -> /tmp/test/a/1
lrwxrwxrwx 1 root root 6 Jul 31 12:39 3 -> ../a/1
Probably there were reasons for that scheme in 7-zip.
As I remember windows for wim stores links with some transformations. And I tried to follow that scheme in 7-Zip's WIM and then it TAR.
@ipavlov The logic makes sense for security considerations. The main concern is that it's expected to extract the links as they are without any transformations if the
-snld
switch is used.7-Zip is an excellent Linux tool as it supports many different formats. It also has one feature that makes it stand out from its alternatives: support for Linux filesystems and image files. With 7-Zip, it's possible to extract those images in a rootless environment such as Docker. I've spent hours trying to find a way to extract images during the Docker image build without granting insecure privileges, and 7-Zip is the only reliable option available at the moment.
My point is that it would be great to be able to extract filesystems as they are with 7-Zip. So far, I found only two issues blocking seamless extraction in a rootless environment — this one and #577. Is there any chance we can consider those as bugs or feature requests?
I don't plan to work for that features now. Maybe later.
You can fix it in source code and recompile binary for youself .