From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1272 invoked by alias); 10 Jul 2010 00:27:24 -0000 Received: (qmail 1258 invoked by uid 22791); 10 Jul 2010 00:27:23 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_CG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 10 Jul 2010 00:27:19 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6A0RHcG001719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Jul 2010 20:27:17 -0400 Received: from [10.3.228.151] (vpn-228-151.phx2.redhat.com [10.3.228.151]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6A0RGme031628 for ; Fri, 9 Jul 2010 20:27:17 -0400 Message-ID: <4C37BE2A.3020501@redhat.com> Date: Sat, 10 Jul 2010 05:28:00 -0000 From: Eric Blake User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5 MIME-Version: 1.0 To: cygwin Subject: Re: tar: symlinks unpacked to empty files (tar security problem?) References: <1278237042.6012.15.camel@YAAKOV04> <20100704171709.GA12616@ednor.casa.cgf.cx> In-Reply-To: <20100704171709.GA12616@ednor.casa.cgf.cx> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA7B76DFE9E7099B73AA294BB" X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2010-07/txt/msg00255.txt.bz2 --------------enigA7B76DFE9E7099B73AA294BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 2449 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". >=20 > 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 !=3D 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. >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org --------------enigA7B76DFE9E7099B73AA294BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 619 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJMN74qAAoJEKeha0olJ0NqrQMIAK6XnSFGZLbuxV/Z0+IG1SgT AnrUgMebiltRNJgEdqDAB/uA3QVkhvFAGSCNVxHLLdNjJnVS7cPvjYqfp+8p2bQE tes6j4uXxHJjlXUz+l+gKiM59XbS4+BypfsCALdTgsIIx+A/moS8jOKN9hGZRo89 EajtGlP18uYICWQJ/6Kxq+o/+kaxlvOE14BNDCfdaTj7dER5njxpbEX5eXj1oMBT iO/TmIaCCpQmJlr6X4NIdPMB7u0bCX+n7WMyIf2GSziJE7gVQHxg+1Yu2tMcp9Bx XQoU/t128aXtVpGLbHI9/cft2JKUJYfkQW8IFcUvd88YesFLOlIPT4eFZAF0pbE= =VA6R -----END PGP SIGNATURE----- --------------enigA7B76DFE9E7099B73AA294BB--