Bug #46384 for CPAN: Bad options used with Archive::Tar

Tue May 26 17:08:01 2009 jd [...] cpanel.net - Ticket created

Subject:

Bad options used with Archive::Tar

In 1.94 CPAN switches from using the system tar and gzip binaries by default for extracting to using Archive::Tar by default for all non-bzip2 archives. This change prevents modules that rely on executable scripts from installing correctly (for instance, Mail::Spamassassin) due to flaws in the way Archive::Tar is being used. In particular, the comment on line 315 of Tarzip.pm is inaccurate: # Make sure AT does not use permissions in the archive # This leaves it to the user's umask instead local $Archive::Tar::CHMOD = 0; Without the chmod, files extracted by Archive::Tar will never have any executable permissions, regardless of umask. Unfortunately it doesn't seem there is any way to do the equivalent of --no-same-permissions with Archive::Tar. At the same time $Archive::Tar::CHOWN is left alone, so extracted files get the (wrong) ownership value contained in the archive.

Thu May 28 03:02:45 2009 ANDK [...] cpan.org - Correspondence added

RT-Send-CC:

chorny [...] cpan.org

Are you saying Archive::Tar is broken or we're just using it wrongly? Or both? Has AT brokenness been reported to the AT queue? Any 'Best' proposal for further proceeding?

Thu May 28 03:02:46 2009 The RT System itself - Status changed from 'new' to 'open'

Thu May 28 08:20:32 2009 jd [...] cpanel.net - Correspondence added

On Thu May 28 03:02:45 2009, ANDK wrote: Show quoted text

> Are you saying Archive::Tar is broken or we're just using it wrongly? Or > both?

I'd say it's a bit of both. It would make sense for Archive::Tar to provide equivalent functionality to tar's --no-same-permissions flag (chmod while applying umask), but it doesn't. Given the limitations Archive::Tar has though, CPAN is using it incorrectly. Show quoted text

> Has AT brokenness been reported to the AT queue?

I'll work up a patch to add --no-same-permisions style behavior and submit a separate report about that. Show quoted text

> Any 'Best' proposal for further proceeding?

Remove the "local $Archive::Tar::CHMOD = 0;" line from Tarzip.pm and add "local $Archive::Tar::CHOWN = 0;" at the same location.

Thu May 28 11:30:59 2009 dagolden [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #46384] Bad options used with Archive::Tar
Date:	Thu, 28 May 2009 11:30:41 -0400
To:	bug-CPAN [...] rt.cpan.org
From:	David Golden <dagolden [...] cpan.org>

On Thu, May 28, 2009 at 8:20 AM, John Lightsey via RT <bug-CPAN@rt.cpan.org> wrote: Show quoted text

> I'd say it's a bit of both. It would make sense for Archive::Tar to > provide equivalent functionality to tar's --no-same-permissions flag > (chmod while applying umask), but it doesn't. Given the limitations > Archive::Tar has though, CPAN is using it incorrectly.

There was a big discussion about the security implications of permissions and the decision taken at the time was to use the user's umask. What in Mail::SpamAssassin requires the executable bit to be set when unpacked and is there an alternative to that assumption? (E.g. Makefile.PL can set anything executable that needs it.) $Archive::Tar::CHOWN is 1 by default and CPAN.pm doesn't change that, so I'm surprised that you're seeing the ownership not change. Which tarball specifically did you observed that on and were you running as root (or under sudo) at the time? -- David

Thu May 28 18:35:57 2009 jd [...] cpanel.net - Correspondence added

On Thu May 28 11:30:59 2009, DAGOLDEN wrote: Show quoted text

> On Thu, May 28, 2009 at 8:20 AM, John Lightsey via RT > <bug-CPAN@rt.cpan.org> wrote:

> > I'd say it's a bit of both. It would make sense for Archive::Tar to > > provide equivalent functionality to tar's --no-same-permissions flag > > (chmod while applying umask), but it doesn't. Given the limitations > > Archive::Tar has though, CPAN is using it incorrectly.

> > There was a big discussion about the security implications of > permissions and the decision taken at the time was to use the user's > umask.

That's understandable, but the $Archive::Tar::CHMOD=0 setting doesn't just apply the umask. It ignores the permissions in the archive and leaves files with whatever permissions they would get with a normal file open/write/close. For instance, if the permissions are 0700 in the archive, $Archive::Tar::CHMOD=0 will leave them as 0644 (assuming umask of 0022.) I'm completely in agreement that Archive::Tar should provide the capability to do the same thing as GNU tar's --no-same-permissions flag though (remove setuid/setgid and apply umask.) Show quoted text

> > What in Mail::SpamAssassin requires the executable bit to be set when > unpacked and is there an alternative to that assumption? (E.g. > Makefile.PL can set anything executable that needs it.)

Mail::Spamassassin's Makefile.PL runs "perl spamc/configure.pl" which in turn runs the autoconf generated "spamc/configure" script with arguments. You could certainly make the argument that CPAN modules should never expect the shebang line to work and should always call /bin/sh explicitly, but it wasn't an issue before CPAN 1.94. NetAddr::IP also fails to install for the same reason. I'd bet there are others, but those are what I see on my system. Show quoted text

> > $Archive::Tar::CHOWN is 1 by default and CPAN.pm doesn't change that, > so I'm surprised that you're seeing the ownership not change. Which > tarball specifically did you observed that on and were you running as > root (or under sudo) at the time?

Right. The ownership in the archive should be ignored. $Archive::Tar::CHOWN=1 only matters when you're running as root and in that circumstance it always does the wrong thing. You don't want CPAN to make lots of files that belong to the random UID's that created the tarballs. For example, when I install Module::Build on my system it gets extracted into the CPAN build directory like this: drwxr-xr-x 3 root root 4.0K May 28 17:15 lib -rw-r--r-- 1 500 defvhost 19K May 3 22:20 LICENSE -rw-r--r-- 1 root root 3.5K May 28 17:15 Makefile -rw-r--r-- 1 500 defvhost 388 May 3 22:20 Makefile.PL If $Archive::Tar::CHOWN was set to 0 these would all be owned by root.

Thu May 28 19:50:08 2009 jd [...] cpanel.net - Correspondence added

Request for tar --no-same-permissions style behavior in Archive::Tar https://rt.cpan.org/Ticket/Display.html?id=46450

Thu May 28 22:57:46 2009 dagolden [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #46384] Bad options used with Archive::Tar
Date:	Thu, 28 May 2009 22:57:29 -0400
To:	bug-CPAN [...] rt.cpan.org
From:	David Golden <dagolden [...] cpan.org>

On Thu, May 28, 2009 at 6:35 PM, John Lightsey via RT <bug-CPAN@rt.cpan.org> wrote: Show quoted text

> That's understandable, but the $Archive::Tar::CHMOD=0 setting doesn't > just apply the umask. It ignores the permissions in the archive and > leaves files with whatever permissions they would get with a normal file > open/write/close. For instance, if the permissions are 0700 in the > archive, $Archive::Tar::CHMOD=0 will leave them as 0644 (assuming umask > of 0022.)

I'm going to call that a bug in Archive::Tar. Glad you reported that there. Show quoted text

> You could certainly make the argument that CPAN modules should never > expect the shebang line to work and should always call /bin/sh > explicitly, but it wasn't an issue before CPAN 1.94. NetAddr::IP also > fails to install for the same reason. I'd bet there are others, but > those are what I see on my system.

I would definitely make that argument unless you actually confirm that /bin/sh is available and unless you know for certain that the shebang line is correct. If your shebang is "#!/usr/bin/perl" and I'm running "/home/david/perl-5.8.9/bin/perl Makefile.PL" then your shebang runs the wrong perl. You absolutely should be executing any perl scripts using $^X. Show quoted text

>> $Archive::Tar::CHOWN is 1 by default and CPAN.pm doesn't change that, >> so I'm surprised that you're seeing the ownership not change. Which >> tarball specifically did you observed that on and were you running as >> root (or under sudo) at the time?

> > Right. The ownership in the archive should be ignored. > $Archive::Tar::CHOWN=1 only matters when you're running as root and in

I think the docs for $Archive::Tar::CHOWN are misleading. I read them to say that CHOWN=1 means "chown to me" not "chown to what was in the tarball". Then I looked at the actual code and saw I was mistaken. You're correct that CPAN::Tarzip should use CHOWN=0. I'll go patch that now and close this ticket. -- David

Thu May 28 23:05:21 2009 dagolden [...] cpan.org - Correspondence added

Fixed in my github master branch: http://github.com/dagolden/cpanpm/commit/6acfe7a9c95fbf1ac8630b5945c0a0564e4aed8c

Thu May 28 23:05:33 2009 dagolden [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Jun 12 14:52:53 2009 jd [...] cpanel.net - Correspondence added

On Thu May 28 23:05:21 2009, DAGOLDEN wrote: Show quoted text

> Fixed in my github master branch: > >

http://github.com/dagolden/cpanpm/commit/6acfe7a9c95fbf1ac8630b5945c0a0564e4aed8c The Archive::Tar 1.50 added more sensible support for dropping the setid bits on files and applying the current umask. Could you change the "local $Archive::Tar::CHMOD = 0;" on line 316 of lib/CPAN/Tarzip.pm to "local $Archive::Tar::SAME_PERMISSIONS = 0;" to make use of this new functionality? This should fix the problems with modules whose installers expect extracted executable files to retain the executable bit.

Fri Jun 12 14:52:54 2009 The RT System itself - Status changed from 'resolved' to 'open'

Fri Jun 12 15:20:46 2009 dagolden [...] cpan.org - Correspondence added

Fixed in my github master branch. CPAN.pm will also warn if Archive::Tar < 1.50 is being used and suggest an upgrade. Thanks for helping to resolve this.

Fri Jun 12 15:20:49 2009 dagolden [...] cpan.org - Status changed from 'open' to 'resolved'