James Carlson <james.d.carlson at sun.com> wrote:
> I see that the odd "cf" overwrite restriction goes away when renamed
> to 'tar'. The other changes do not.
>
> I'm using star 1.5a74. I've also tried 1.5a80 with the same results.
> Perhaps there's a newer version that lacks incompatibilities. I don't
> know, and this really isn't the thread in which to discuss such
> things. Instead, this should be the topic of a future case that
> proposes replacing /usr/bin/tar. As pointed out repeatedly, this is
> _not_ that case, and that case does _not_ exist.
a74 is a bit old (more than a year). The current release is 1.5a83.
1.5a80 introduced the ability to tell star to be a bit more insecure.
These new features allowed me to implement to implement undocumented behavior
from Sun tar and Sun cpio (the related behavior is neither documented in Sun's
man pages nor in the POSIX/SUSv2 standard). BFU depends on the undocumented
behavior implemented by Sun cpio and a lot of users believe that "tar" should
have some specific behavior in extract mode. The implemented "features" should
be documented. I am sure that nobody really _knows_ that "tar" will remove any
non-directory file (or empty directory) before extracting an object of te same
name from the archive. I am also sure that nobody knows that cpio will even
remove _non-empty_ directories without asking before.....
Note that the features found in 1.5a80 are a result of my discussions about star
integration to ON that I had with Joseph Kowalski.
If you like to check "compatibility", you need to use 1.5a80 or newer.
> Observe:
>
> % ls -l /opt/csw/bin/tar
> lrwxrwxrwx 1 root root 4 Jul 31 11:21 /opt/csw/bin/tar -> star
> % /opt/csw/bin/tar --version
> suntar: star 1.5a80 (sparc-sun-solaris2.8)
>
> Copyright (C) 1985, 88-90, 92-96, 98, 99, 2000-2007 J?rg Schilling
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> % /opt/csw/bin/tar cf foo.tar /tmp/motd
> /opt/csw/bin/tar: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k).
> % /opt/csw/bin/tar xf foo.tar /tmp/motd
> /opt/csw/bin/tar: WARNING: skipping leading '/' on filenames.
> /opt/csw/bin/tar: '/tmp/motd' did not match
> /opt/csw/bin/tar: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k).
>
> There's the first incompatibility. It fails to match files that are
> clearly in the archive, because it's errantly skipping over the
> leading '/' mark.
>
> % /opt/csw/bin/tar xf foo.tar
> /opt/csw/bin/tar: WARNING: skipping leading '/' on filenames.
> /opt/csw/bin/tar: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k).
> % ls -l /tmp/tmp/motd
> -rw-r--r-- 1 carlsonj staff 720 Aug 16 11:22 /tmp/tmp/motd
>
> There's the second incompatibility. It's extracting to a different
> location than the one that was archived.
TAR is usually used to extract files to a different location than the files
did have when creating the archive, This is because tar was not originally
written as a backup program.
UNIX in general behaves as "Garbage In -> Garbage Out". The examples you did
make met the "Garbage In" condition. You will not get reasonable results
with this kind of input.
> I understand _why_ this was done and the security problems inherent in
> (especially) allowing root to extract absolute files from an archive.
> However, at the same time, this change is not compatible and _will_
> break consumers that rely on the existing behavior.
These customers did ignore all FAQs that are available for archivers on UNIX.
These FAQs tell you _not_ to put absolute path names into archives.
If you are looking for a bug, then you found it in the archives that use
absolute path names but not in star's default behavior. As the behavior may be
changed by specifying -/, I see no problem with staying "secure by default".
As I mentioned before, the POSIX standard does not forbid to by default
disallowing the extraction of files that come with an absolute path name in the
archive. Ignoring the resulting problems creates a serious vulnerability in the
OS. For this reason, there is no way to discuss _whether_ to forbid such files
by default. There is however room to discuss _how_ an archiver should handle
the problem by default. If you are interested in technical based discussion,
we could start to discuss _how_ to handle the problem... I am always open to
better proposals!
> It's unclear to me whether the stderr spewage will break anything, but
> I wouldn't be surprised if it does. Most common utilities don't write
> to stderr unless there's actually an error. Sending success messages
> there is really strange.
As I mentioned before, the star code is fully configurable and whether or not
to supress an informational message that is similar to dd(1) and that exists in
star since 1984 _is_ negotiable. Note that cpio from AT&T does print a similar
message and that this message may not be swithced off.
BTW: I invite everybody who is interested in a technical based discussion and
open for better proposals to discuss the star integration on:
star-discuss at opensolaris.org
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
