[Bug 1519] New: hardlink of symlink in archive messes up permissions

bugzilla at busybox.net bugzilla at busybox.net
Thu Apr 8 11:52:58 UTC 2010


https://bugs.busybox.net/show_bug.cgi?id=1519

           Summary: hardlink of symlink in archive messes up permissions
           Product: Busybox
           Version: 1.16.x
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: Other
        AssignedTo: unassigned at busybox.net
        ReportedBy: nils.rennebarth at arcor.de
                CC: busybox-cvs at busybox.net
   Estimated Hours: 0.0


If an archive contains a hardlink of a symlink, extracting the hardlink messes
up the permissions of the real file.
Assume the following situtation (under linux, other OS may behave differently,
but I heard Solaris does the same)

$ touch file
$ ln -s file link
$ mkdir dir
$ ln file dir
$ ln link dir

Now dir will contain two hardlinks, one named "file" and one named "link"
When GNU tar creates an archive of all this and busybox tar extracts it,
the "file" will have permission 777.

The bug lies in archival/libunarchive/data_extract_all.c, where hardlinks
are first handled separately (line 73-80), but later chown and chmod is
performed, and that is done by chmod itself, which uses the
permissions of the symlink which are always 777.

I would argue that a hardlink has no permissions (nor timestamps nor
uid/gid) itself, because all that data is in the inode. And the code
relies on the existance of the link target already, so my proposal
for a fix would be to simply return on line 80.


-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the busybox-cvs mailing list