From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 00:48:57 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64DBB95D for ; Thu, 9 Oct 2014 00:48:57 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26A6A7FA for ; Thu, 9 Oct 2014 00:48:56 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id h18so1158821igc.0 for ; Wed, 08 Oct 2014 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=goK1vjay1Ql22gSeBvvsTvAKRGtWQhLDrVxRxoDBPjQ=; b=MPYQeHJyGqJigWIHfyJc0+TQopSsE0Acw5zmrK0XCuWhatdnfkEPNrFytZeBisTzSY 5216+08yyLK9yLXKTr4/eO+iJ0W6FMEJbEwCwzLTA7ionCgnrNSuH1XxkieXfsDrmLm+ LDcp3OJN8C7qOBLCu/cNT0qdGcXR82wekgPY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=goK1vjay1Ql22gSeBvvsTvAKRGtWQhLDrVxRxoDBPjQ=; b=cw+b4oB/SQ207zSPWpihluzevAfmabY9vezoaTIQPztl/XGxiAguEUJY+vrI7uKBbv tuNAaTj5EvOFgvqSWjT04dwDwCzc06TtfF3SbPYKvh4/0y6brQ0iIchPLubaUghy7cVE Gr0SWTEiwqdShNTDeyOPu8KNKpaYhn9m/D19QHfB6+IMxezIbSdf2QgFwDHtqBHlTcqr 7mq70EvDGhjbfbTyruhwI7I+EvuEHUItRg1FyWl9UfHUlGCY6eQir8w6vUiEJ6Q5N/CA Nid8w1zoiZylJfs6bFsmKBMyoZXaXfFAFgGzIa1+QKVwHmfQjyhhKQTtmel8KrRyDIyf yUFg== X-Gm-Message-State: ALoCoQkLDZICWm1JKHGkv69QE5E0NZttvS9WlgR82MVedMEFLM5+Nhy+3FpWpILLHZZseFUn8D/X X-Received: by 10.50.61.99 with SMTP id o3mr2534156igr.30.1412815735929; Wed, 08 Oct 2014 17:48:55 -0700 (PDT) Received: from ?IPv6:2600:1008:b101:c87a:9068:545b:6c4b:7b29? ([2600:1008:b101:c87a:9068:545b:6c4b:7b29]) by mx.google.com with ESMTPSA id ky8sm3189311igb.16.2014.10.08.17.48.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 17:48:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: tar and / From: Jason Hellenthal X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Wed, 8 Oct 2014 19:48:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <221B7CFC-4AE2-4DAF-9E6E-565715B87172@dataix.net> References: To: Daniel Braniss Cc: "hackers@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 00:48:57 -0000 Damn! I thought we were past this issue long ago using relative paths instea= d absolute paths. Wonder what ever happened to that standard of safety. Unle= ss I am mistaking one thing for another. Symbolic links obviously should not be starting with "/".=20 Hard links on the other hand should be broken once inside a tar file and no l= onger referencing a previous inode. So if I understand this correctly this i= s what you are seeing ? On another note from this ... I was by aware hard links could be created to a= nything but files ... ? So I'm confused here ? --=20 Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal@DataIX.net JJH48-ARIN On Oct 8, 2014, at 01:24, Daniel Braniss wrote: A facts that I did not mention: the tar file is created by ports when requesting =E2=80=98package=E2=80=99= , it now adds /usr/local making extraction difficult for those that use nfs/amd for /usr/local (the solution is to extract the files in /var/tmp, and re-taring without the= /usr/local :-) to my surprise, even though tar complains that it can=E2=80=99t do the link t= o / it actually does the link!! notice that I mentioned =E2=80=98link', not symlink! which of course brings t= he question why some ports insist on link, and not symlink is beyond me. thanks danny > On Oct 7, 2014, at 5:35 PM, Jason Hellenthal wrot= e: >=20 > =46rom tar(1) >=20 > o Archive entries can exploit symbolic links to restore files to o= ther directories. > An archive can restore a symbolic link to another directory, th= en use that link to > restore a file into that directory. To guard against this, tar= checks each > extracted path for symlinks. If the final path element is a sy= mlink, it will be > removed and replaced with the archive entry. If -U is specifie= d, any intermediate > symlink will also be unconditionally removed. If neither -U no= r -P is specified, > tar will refuse to extract the entry. >=20 > With that stated you might want to roll through your filesystem with symli= nks(1) [sysutils/symlinks]. Use of this to shorten, remove dangling etc.. >=20 > DESCRIPTION > symlinks is a useful utility for maintainers of FTP sites, CDROMs, a= nd > Linux software distributions. It scans directories for symbolic lin= ks > and lists them on stdout, often revealing flaws in the filesystem tre= e. >=20 > Each link is output with a classification of relative, absolute, da= n- > gling, messy, lengthy, or other_fs. >=20 > relative links are those expressed as paths relative to the directo= ry > in which the links reside, usually independent of the mount point o= f > the filesystem. >=20 > absolute links are those given as an absolute path from the root dire= c- > tory as indicated by a leading slash (/). >=20 > dangling links are those for which the target of the link does not cu= r- > rently exist. This commonly occurs for absolute links when a filesy= s- > tem is mounted at other than its customary mount point (such as wh= en > the normal root filesystem is mounted at /mnt after booting from alte= r- > native media). >=20 > messy links are links which contain unnecessary slashes or dots in t= he > path. These are cleaned up as well when -c is specified. >=20 > lengthy links are links which use "../" more than necessary in the pa= th > (eg. /bin/vi -> ../bin/vim) These are only detected when -s is spec= i- > fied, and are only cleaned up when -c is also specified. >=20 > other_fs are those links whose target currently resides on a differe= nt > filesystem from where symlinks was run (most useful with -r ). >=20 > Hope this helps. >=20 >> On Oct 7, 2014, at 1:44, Daniel Braniss wrote: >>=20 >> hi,Ian Lepore >> for security reasons tar removes the leading /, which is fine. >> so I can chadir to /var/tmp, and do an extract there. The problem arises w= hen there >> is a file that is linked to /=E2=80=A6 >> Is there some way to drop that leading =E2=80=98/=E2=80=98 too? >>=20 >> cheers, >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >=20 > --=20 > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal@DataIX.net > JJH48-ARIN