Date: Sat, 10 Jul 2010 01:28:17 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: tar: symlinks unpacked to empty files (tar security problem?)
Message-ID: <20100710052817.GA27998@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <1278237042 DOT 6012 DOT 15 DOT camel AT YAAKOV04> <20100704171709 DOT GA12616 AT ednor DOT casa DOT cgf DOT cx> <4C37BE2A DOT 3020501 AT redhat DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C37BE2A.3020501@redhat.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Fri, Jul 09, 2010 at 06:26:18PM -0600, Eric Blake wrote:
>On 07/04/2010 11:17 AM, Christopher Faylor wrote:
>> On Sun, Jul 04, 2010 at 04:50:41AM -0500, Yaakov (Cygwin/X) wrote:
>>> With tar-1.23-1 and recent snapshot:
>>>
>>> echo foo > foo
>>> ln -s $PWD/foo bar
>>> tar cf test.tar bar foo
>>> rm -f bar foo
>>> tar xf test.tar
>>> ls -l bar foo
>>>
>>> You will see that 'bar' is a 0-byte file with 0000 permissions instead
>>> of a symlink.  The symlink reference need not be absolute; it also
>>> happens with relative links in different directories, but does not
>>> happen if I just "ln -s foo bar".
>> 
>> That's because of the way that tar handles symlinks.  If you have a
>> reference to an absolute path, tar makes a zero-length regular file
>> placeholder.  Then when it is done extracting, tar is supposed to remove
>> this file and create the real symlink.  However, the test to make sure
>> that it is ok to do this was broken by a recent DLL change.  The inode
>> returned the first time that the file was created was != the inode when
>> the file is checked later.  So tar thought that the zero-length file was
>> modified and silently decided not to create the symlink.
>
>For the longest time, I was carrying a cygwin-specific patch that
>ignored the inode check.  Thinking that it was leftovers from 1.5, I
>removed that cygwin-specific patch (that is, re-enabled the inode
>check), because I didn't have a test case that would trigger it.  It
>looks like you have demonstrated the test case, and if cgf fixed the dll
>to report the same inode in both situations, then great.  But since I'm
>on vacation at the moment, with only limited email access, it will be
>another week before I can even think about re-building tar to re-enable
>the cygwin-specific patch.  I'll do that, unless cygwin 1.7.6 is
>released first and fixes the problem in the meantime.

AFAIK, this was a problem only in snapshots so there is no reason for a
new release.

cgf
(who's also on vacation)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple