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. > 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. 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. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Attachment:
signature.asc
Description: Digital signature