Issue Summary
When extracting an archive with GNU tar version 1.35 that contains symbolic links, the extracted symlink permissions incorrectly respect the user's umask instead of defaulting to 777. This behavior occurs under specific conditions and differs from previous versions (e.g., 1.33), where symlinks were always created with mode 777 as expected.
Conditions
- Extraction is performed by a non-root user.
umask is set to 027 (or 022).- Archive contains symbolic links.
Expected Behavior
By definition, symbolic links should always have permissions lrwxrwxrwx (mode 777), regardless of umask.
Observed Behavior
The extracted symlink inherits permissions based on umask. For example:
- With
umask 027, the symlink is created as lrwxr-x--- (mode 750).
This causes issues for operations that expect standard symlink permissions, such as cp -hrp.
Steps to Reproduce
# run under non-root local user
mkdir symlink_test && cd symlink_test
TAR=/opt/freeware/bin/tar
$TAR --version # returns 1.35
ln -s /etc/resolv.conf symlink
# ls -l symlink returns:
# lrwxrwxrwx 1 test_user test_user 16 Dec 08 14:41 symlink -> /etc/resolv.conf
$TAR cvf archive.tar symlink
rm symlink
umask 027
$TAR xvf archive.tar symlink
# lrwxr-x--- 1 test_user test_user 16 Dec 08 14:45 symlink -> /etc/resolv.conf
cp -hrp symlink symlink2
cp: not all requested changes were made to symlink2
ls -l symlink*
lrwxr-x--- 1 test_user test_user 16 Dec 08 14:55 symlink -> /etc/resolv.conf
lrwxrwxrwx 1 test_user test_user 16 Dec 08 14:56 symlink2 -> /etc/resolv.conf
Impact
- Breaks scripts and tools relying on standard symlink permissions.
- Causes unexpected permission errors during file operations.
Workaround
Downgrading to GNU tar 1.33 or earlier resolves the issue.
We have not seen the same issue on Linux (gnu tar 1.35, Ubuntu 24.04).
------------------------------
Jozef Riha
------------------------------