GNU bug report logs - #7379
On the fix for CVE-2009-4029 Automake security fix for 'make dist*'

Previous Next

Full log

View this message in rfc822 format

From: Behdad Esfahbod <behdad <at> behdad.org>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7379 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>, Jim Meyering <jim <at> meyering.net>
Subject: bug#7379: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
Date: Wed, 17 Nov 2010 11:26:50 -0500

Hi Ralf,

Scroll down for my comments.


On 11/13/10 03:00, Ralf Wildenhues wrote:
> [ Thanks Glenn for rerouting the bug report! ]
> 
> Hi Behdad,
> 
>> From: Behdad Esfahbod
>> Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
>> Date: Thu, 11 Nov 2010 16:17:22 -0500
> 
>> I recently read about the fix for the chmod 777 issue.  Just wanted to note
>> that it may be preferred if you continue with chmod 777 and instead fix the
>> problem by moving the dist dir inside another direction that is 700.
>>
>> The reason a 777 mod in the tarball may be preferred (or 775 for that matter,
>> but not 755) is for systems that users of a group are using sticky-bit on the
>> group to share writable files with eachother.  By letting the umask decide
>> what bits should not be set you you enable such settings, whereas using 755,
>> the user expanding the tarball has to reset it to 775 or the rest of the group
>> cannot write to it.
> 
> Thanks for the bug report.  At the time we fixed this, we considered
> going this other option.  It was a fairly close call.  The downside of
> the solution you suggest was that it would complicate 'make dist' a
> little, and maybe break a few packages that rely on the exact subdir
> structure of $(distdir) being one directory below the toplevel build
> directory.  Such reliance is probably bad style anyway, but we didn't
> know of many uses that would benefit from more relaxed permission inside
> the tarball.  How useful is that for you, how come you don't use a
> version control repository rather than an extracted tarball for
> collaborative work (honest question)?
> 
> You are the first person to report this in the 12 months since we
> released fixed versions of Automake.  I don't have other data to go on
> but it thus doesn't seem to be a very wide spread issue to me, and
> there's the obvious workaround of a chmod -R after extraction, no?


When I read about the fix, this was the first thing that popped into my mind.
 I didn't actually hit this issue.

But I agree: most probably no one actually relies on the permissions being
correct right off the tarball anyway.

Cheers,
behdad

> I'm open to arguments here, but so far I'm slightly leaning toward
> keeping the current behavior.
> 
> Thanks,
> Ralf
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.