Hi Niko Sorry for the delay.
On Sat, 6 Dec 2008 11:12:08 pm Niko Tyni wrote:
> 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.
I had a read through the issue and to me it sounds like pristine-tar is broken
or at least expects the perl-module to work, where it IMHO should have never
worked. I am wondering how many packages are affecting by this or assuming
this behaviour.
Could you build updated packages and give them to Joeyh and Stefano (both
CC'ed now, pasting an URL to the bugreports would be best I guess). It would
be great, if they could do some more extensive testing in their environments.
I'll have a more careful read through the issue during the next days.
Cheers
Steffen
signature.asc
Description: This is a digitally signed message part.
