fixed 479317 perl/5.8.8-7
found 479317 perl/5.8.8-7etch5
found 479317 perl/5.10.0-1
thanks
Hi security team,
I'm sorry to report that we have a regression with perl/5.8.8-7etch5.
As reported in #479317 originally for the 5.10 branch, removing the
current working directory with File::Path::rmtree() now fails. This
makes File::Temp::tempdir() croak at END time if CLEANUP is set to 1
and the user has chdir()'d into the temporary directory.
Joey's testcase in #479317 is
# perl -e 'use File::Temp; my $t=File::Temp::tempdir(TMPDIR => 1, CLEANUP =>
1); mkdir("$t/foo"); chdir "$t/foo"; print "now exiting\n"'; echo $?
which gives on -etch3 just
now exiting
0
while on -etch5 it gives
now exiting
Can't return to /tmp/BV403sAeev/foo from /tmp/BV403sAeev (No such file or
directory) at /usr/share/perl/5.8/File/Temp.pm line 898
END failed--call queue aborted.
2
I suspect the ytnef regression in #507890 is related, but haven't been
able to reproduce it yet.
The old rmtree() implementation didn't use chdir() at all (which lead
to the race conditions), so it didn't have to worry about returning to
the same place.
However, now that we do, we need to trace the path back while avoiding
things like CVE-2002-0435 (somebody moving a lower directory higher in the
hierarchy so that chdir('..') leads to for instance the root directory).
I think the attached patch could fix the compatibility issue. It's only
lightly tested at this point, but at least the test suite passes.
The idea is to pass the depth information to _rmtree() so that we abort
only on further recursive _rmtree() calls.
If returning to the directory where rmtree() was originally called
fails ($depth == 0), the function returns successfully and leaves the
process into the deleted directory to further emulate the old behaviour.
It's not the same deleted directory as in the old implementation, but
at least relative filenames will never match there.
Please comment, more eyeballs are just as welcome as earlier.
--
Niko Tyni [EMAIL PROTECTED]
>From 6ada5878da1f7d8967877fc423dcc8c4db32c542 Mon Sep 17 00:00:00 2001
From: Niko Tyni <[EMAIL PROTECTED]>
Date: Sat, 6 Dec 2008 23:19:10 +0200
Subject: [PATCH] Fix a regression in File::Path::rmtree() introduced in 5.8.8-7etch5. (Closes: #479317)
File::Path::rmtree() no longer aborts on removing the current working
directory.
---
lib/File/Path.pm | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/lib/File/Path.pm b/lib/File/Path.pm
index 0c5afeb..651c1a7 100644
--- a/lib/File/Path.pm
+++ b/lib/File/Path.pm
@@ -160,7 +160,7 @@ sub mkpath {
sub _rmtree;
sub _rmtree
{
- my ($path, $prefix, $up, $up_dev, $up_ino, $verbose, $safe) = @_;
+ my ($path, $prefix, $up, $up_dev, $up_ino, $verbose, $safe, $depth) = @_;
my ($dev, $ino) = lstat $path or return 0;
unless (-d _)
@@ -206,7 +206,7 @@ sub _rmtree
next if $entry =~ /^\.\.?$/;
$entry =~ /^(.*)$/s; $entry = $1; # untaint
$count += _rmtree $entry, "$prefix$path/", '..', $dev, $ino,
- $verbose, $safe;
+ $verbose, $safe, $depth + 1;
}
closedir $dir;
@@ -223,7 +223,14 @@ sub _rmtree
# don't leave the caller in an unexpected directory
unless (chdir $up)
{
- croak "Can't return to $up from $prefix$path ($!)";
+ if ($depth == 0) {
+ # compatibility; see http://bugs.debian.org/479317
+ carp "Warning: can't return to $up from $prefix$path ($!)"
+ if $verbose;
+ return $count;
+ } else {
+ croak "Can't return to $up from $prefix$path ($!)";
+ }
}
# ensure that a chdir .. didn't take us somewhere other than
@@ -279,7 +286,7 @@ sub rmtree
my $count = 0;
for my $path (@paths)
{
- $count += _rmtree $path, '', $oldpwd, $dev, $ino, $verbose, $safe;
+ $count += _rmtree $path, '', $oldpwd, $dev, $ino, $verbose, $safe, 0;
}
$count;
--
1.5.6.5
