bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7379: On the fix for CVE-2009-4029 Automake security fix for 'make d


From: Ralf Wildenhues
Subject: bug#7379: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
Date: Sat, 13 Nov 2010 09:00:37 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

[ 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?

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

Thanks,
Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]