This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id:
46384
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
jd [...] cpanel.net
Cc:
AdminCc:

BugTracker
Severity:
Important
Broken in:
1.94
Fixed in:
(no value)



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.
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?
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.
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
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.
Request for tar --no-same-permissions style behavior in Archive::Tar https://rt.cpan.org/Ticket/Display.html?id=46450
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
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.
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.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.