Bugzilla Bug 79685

Paul Szabo brought to our attention that the fix for CAN-2004-0452 does not
handle all race conditions case and that rmtree is still vulnerable :

=============================================
Just changing the chmod to 0700 and 0600 instead of 0777 and 0666
does NOT solve the issue. The chmod change was for another, but related,
problem. See bugs.debian.org/286905 and 286922.
=============================================

Looking for a definitive patch for this issue.

Comments about rmtree committed into Owl release :

==========================
There're race conditions internal to the implementation of <rmtree> making it unsafe to use on directory trees which may be altered or moved while <rmtree> is running, and in particular on any directory trees with any path components or subdirectories potentially writable by untrusted users.

Additionally, if the third parameter is not TRUE and <rmtree> is interrupted, it may leave files and directories with permissions altered to allow deletion (and older versions of this module would even set files and directories to world-read/writable!)

Note also that the occurrence of errors in <rmtree> can be determined only by trapping diagnostic messages using $SIG{__WARN__}; it is not apparent from the return value.
=========================

Maybe we should "fix" this by documenting it like this.

I think we should close this one. rmtree has race conditions by design...
Comments ?

Created an attachment (id=52935) [details]
rmtree.patch

Patch from Debian (applies cleanly if you don't apply the previous
file_path_rmtree.patch)

Warning! This patch seems to ignore macos specific code:

"I've also ignored $Is_VMS and $Is_MacOS; will need some input from
perl5-porters as to what changes are required to support those
platforms."

CAN-2005-0448

Perl team, please apply patch or comment...

Are we worried about macos support (which is lacking in this patch) (and i see
them lurking over my shoulder)?

I still want to say that this patch doesn't defeat the race condition, but
comes pretty close (relies on the inode/stat of the dir comparing before and
after a chdir). Would this still work on an nfs mount where the nfs sync wasn't
running up to par, ie, changes made on another server with the nfs mount don't
get replicated across until after the chdir occurs? just saying...

for general purpose uses, yes, this patch should cover most cases, and I may be
overthinking/misunderstanding it :)

I think we can commit this and forget to add macos keywords, and let them patch
the patch if needed when they add their own keywords ? Or we can pull them in
so that they do it now.

Adding ppc-macos herd to the mix.

Go ahead and push it through. ppc-macos will not be keywording anything perl in
the near future.

Confirmed that it applies and runs smoothly on all three versions in the tree.
Are we good for a version bump & release or do you need time?

Micheal please go ahead.

Posted and bumped across the board.

Thx Micheal. This one is ready for GLSA vote.

STOP. I messed up somewhere and need to roll back and get this fixed. I read
the patch, read it as clean, but as soon as it hit the tree I started getting
bug reports against it. I accept responsibility for this,

Mike

I'm rolling back until we can get a better solution. This patch will break this
module on any box that changes kernel versions. I don't deny that a fix is
needed, but the problem is that in using Errno, it uses
/usr/lib*/perl5/<current-version>/<archversion>/Errno.pm (path varies depending
on arch), which records your kernel version/platform at install. This patch
invokes it and throws an error for anyone that has changed kernels.

back to [ebuild] status.

I don't know if I've ever had such a frantic session...fixed. For good.
Patching from a better location in the process.

Nice save Michael :)

Security, please vote on GLSA.

I vote yes, as an update to GLSA 200501-38

I vote YES to the GLSA update as well.

I'll do it

Released as GLSA 200501-38:03 update