[1443] in linux-security and linux-alert archive
[linux-security] Re: GNU tar vulnerability
daemon@ATHENA.MIT.EDU (Frangois Pinard)
Fri Feb 7 04:04:13 1997
Date: Thu, 6 Feb 1997 18:51:23 -0500
From: "Frangois Pinard" <pinard@progiciels-bpi.ca>
To: jlewis@inorganic5.fdt.net
CC: mouse@holo.rodents.montreal.qc.ca, BUGTRAQ@netspace.org, bje@air.net.au,
linux-security@redhat.com, benedikt@devnull.ruhr.de,
Forum of GNU tar pretesters <tar-forum@iro.umontreal.ca>
In-reply-to: <Pine.LNX.3.95.970126151019.161d-100000@inorganic5.fdt.net>
(message from Jon Lewis on 1997-01-26 15:16:18-05:00 (EST))
Reply-to: pinard@iro.umontreal.ca
Resent-From: linux-security@redhat.com
| > > GNU tar is lazy about file creation modes and file owners when
| > > unpacking a tar file.
| On Sat, 25 Jan 1997, der Mouse wrote:
| >
| > Whaaaaat? [...]
Hello, Mike. I'm just remembering your voice, and am really *hearing*
you when I read that :-) :-).
| > If GNU tar, by default, uses a private header format that contains
| > string names instead of the numeric UID and GID info a standard tar
| > header block holds, IMO that is a crippling bug, because it will
| > render it uninteroperable.
Oh, it is not a private format. It is roughly POSIX. GNU tar already
supports old V7 format, a few BSD idiosyncrasies, and an obsolete draft
of POSIX ustar format. Maintainers (before me) added extensions to that
draft format, in such a way that it is now incompatible with the more
recent POSIX ustar format, and put GNU tar in a difficult position as
for its evolution. I'm trying to correct that. I now have to support
all previous formats while reading archives, including a few different
ways for implementing long file names, and some new format I'm trying to
devise for accommodate GNU extensions, in a way which is more respectful
of latest POSIX extension mechanisms. Yet, a bit uncomfortably, I'm
under pressure to use some extra free space at the end of the current
(comparatively new) POSIX header, so files will usually not need any extra
header block for the cases which are most common in GNU and elsewhere.
However, the exact ways are not completely decided, and I would surely
be happy to have a lot of feedback and opinions before they crystallise.
GNU tar has an option to generate old (V7) headers, this option will be
kept. By default right now, it generates obsolete-POSIX GNU-augmented
headers -- not wonderful for interchange, I agree, yet real problems
seem to be infrequent in practice. My current goal is to generate
latest-POSIX headers by default, with some extra values in the last few
undefined bytes of the POSIX block, and to generate extension blocks for
less usual GNU specialities (like volume labels, multi-volume resuming,
and such strangeties). There will also be an option to force stricter
POSIX conformance, and so, to disallow most GNU extensions.
| I've found that GNU tar will create files owned by uids/gids not in
| /etc/passwd...but it seems to only do so when I don't necessarily
| need it to. I often see this happen when untaring new sources into
| /usr/local/src/.
POSIX headers have both numeric and symbolic identification for owners
and groups. If symbolic identification succeeds at extraction time,
it may imply ignoring the stored numeric identification, so effectively
changing from the numeric value stored into the archive. Only a few days
after the release of GNU tar 1.11.8, I made some cleanup in this area:
there was a long lasting bug by which restored files were all owned by
root if using an incomplete /etc/passwd or /etc/group file. They now
use the stored numeric identification if the symbolic identification is
not successful. (All this either as root, or as user with the -p option
on systems allowing users to give away their files --- in which case
special bits are duly reset --- hoping I remember correctly.) I also
added an option for GNU tar to merely ignore all symbolic identification.
| When restoring a full backup to a blank disk, I've found that if the
| /etc/passwd isn't restored first, all user files (and nearly everything
| else) will end up owned by root.
Many GNU tar users considered this to be a bug and reported it as such.
As I implied earlier, this should be corrected in the next real release.
It has already corrected in pretest releases for quite a while by now.
If you have any further comment on these matters, be sure they reach me,
either by mailing directly to the address in my signature (or Reply-To:
field), to <tar-bugs@gnu.ai.mit.edu> or to <tar-forum@iro.umontreal.ca>.
I'm not on the security lists to which this reply is being sent.
=09=09=09Thanks for your collaboration, everybody.
[mod: I hope this wraps it up. -- REW]
--
Fran=E7ois Pinard ``Vivement GNU!'' pinard@iro.umontreal.ca
Support Programming Freedom, join our League! Ask lpf@lpf.org for info!
