Am 23.10.2014 um 03:09 schrieb brian m. carlson:
On Wed, Oct 22, 2014 at 11:42:48AM +0200, Michael J Gruber wrote:
Junio C Hamano schrieb am 21.10.2014 um 20:14:
Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries.
Is an extended pax header "an archive entry"? I doubt it, and the
above is not relevant. The mode bits for the archive entry that it
applies to does not come from there.
The problem seem to be old tar versions which mis-take the extensions
for archive entries, aren't they?
Yes. POSIX isn't clear on how unknown entries are to be handled. I've
seen some Windows tar implementations extract GNU longlink extensions as
files, which leads to a lot of pain.
That's by design -- extended headers are meant to be extracted as plain
files by implementations that do not understand them.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html says:
"If a particular implementation does not recognize the type, or the user
does not have appropriate privilege to create that type, the file shall
be extracted as if it were a regular file if the file type is defined to
have a meaning for the size field that could cause data logical records
to be written on the medium [...]."
My question to Brian still stands which existing users he was trying to
cater for with his patch. If there indeed are no existing affected users
besides the KUP users (as you seem to assume) it's a clear case. Pun
intended ;)
The pax format is an extension of the tar format. All of the pax
implementations I've seen on Linux (OpenBSD's and MirBSD's) don't
actually understand the pax headers and emit them as files. 7zip does
as well. I expect there are other Unix systems where tar itself doesn't
understand pax headers, although I don't have access to anything other
than Linux and FreeBSD.
NetBSD's tar does as well.
It's surprising and sad to see *pax* implementations not supporting pax
extended headers in 2014, though. It seems long file names etc. are not
common enough. Or perhaps pax is simply not used that much.
Since it's very common to extract tar archives in /tmp, I didn't want to
leave world-writable files in /tmp (or anywhere else someone might get
to them). While the contents probably aren't sensitive, a malicious
user might fill someone's quota by "helpfully" appending /dev/zero to
the file. And yes, users do these things.
The extracted files are only world-writable if umask & 2 == 0 or if -p
(preserve permissions) has been used, no?
René
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html