tar: symlinks unpacked to empty files

tar: symlinks unpacked to empty files

[Yaakov (Cygwin/X)]

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".


Yaakov



--
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

Re: tar: symlinks unpacked to empty files (tar security problem?)

[Christopher Faylor]

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.

I've fixed the cygwin problem - it should be in the next snapshot.  I
think this silent behavior of tar is not too user friendly though.  It
seems like there is a pathological situation there where you'd end
thinking that you'd extracted a symlink without getting the symlink.  In
fact, I think this is actually a security problem.

Eric, am I missing something about tar's behavior here?

cgf

--
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

Re: tar: symlinks unpacked to empty files (tar security problem?)

[Yaakov (Cygwin/X)]

On Sun, 2010-07-04 at 13:17 -0400, Christopher Faylor wrote:
> 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.
> 
> I've fixed the cygwin problem - it should be in the next snapshot.

It appears to be working with 20100704 snapshot.  Thanks for the quick
response.


Yaakov



--
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

Re: tar: symlinks unpacked to empty files (tar security problem?)

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]

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.

> I've fixed the cygwin problem - it should be in the next snapshot.  I
> think this silent behavior of tar is not too user friendly though.  It
> seems like there is a pathological situation there where you'd end
> thinking that you'd extracted a symlink without getting the symlink.  In
> fact, I think this is actually a security problem.
> 
> Eric, am I missing something about tar's behavior here?

You're probably right that this should be reported upstream as a
potential hole, where tar should not be silent about failure to restore
a file.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: tar: symlinks unpacked to empty files (tar security problem?)

[Christopher Faylor]

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