Re: Sources for 3.18-rc1 not uploaded

From: René Scharfe <l.s.r@web.de>
Date: Oct 26, 2014, 18:59 UTC
Message-ID: <544D44AB.1080305@web.de>
In-Reply-To: <20141023010927.GE312818@vauxhall.crustytoothpaste.net>

Am 23.10.2014 um 03:09 schrieb brian m. carlson:

Show 17 quoted lines

> 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@drmicha.warpmail.net> 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 [...]."

Show 11 quoted lines

>> 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.

Show 5 quoted lines

> 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é