tar(1) on noble gives EPERM [Operation not permitted] errors when extracting symlinks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tar (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
This concerns tar 1.35+dfsg-3 in Ubuntu noble. This does NOT affect tar 1.34+dfsg-
I'm seeing errors like this:
$ tar xvJf /extern/
chromium-
tar: chromium-
(I am running this in a noble Docker container environment, and the command is extracting into normal user file space.)
This is what strace shows:
23 symlinkat(
23 utimensat(AT_FDCWD, "chromium-
23 newfstatat(
23 fchmodat2(AT_FDCWD, "chromium-
The fchmodat(2) man page has the following verbiage:
AT_SYMLINK_
If pathname is a symbolic link, do not dereference it: instead
operate on the link itself. This flag is not currently imple‐
mented.
For comparison, this is what happens on mantic:
24 symlinkat(
24 utimensat(AT_FDCWD, "chromium-
24 newfstatat(
24 openat(AT_FDCWD, "chromium-
24 newfstatat(3, "", {st_mode=
24 close(3) = 0
summary: |
- tar(1) gives EPERM errors when extracting symlinks + tar(1) on noble gives EPERM [Operation not permitted] errors when + extracting symlinks |
Tracked down the cause to the Docker host, which runs on jammy, not knowing about fchmodat2(). The syscall should normally return ENOTSUP when called with AT_SYMLINK_NOFOLLOW on Linux, but the Docker seccomp profile causes it to return EPERM, which confuses tar(1). Closing.