Bug 1572500

Summary: rmtree with safe = 0 does not work
Product: Red Hat Software Collections Reporter: Martin Kyral <mkyral>
Component: perl-File-PathAssignee: perl-maint-list
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rh-perl526CC: ppisar
Target Milestone: ---   
Target Release: 3.7   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1584709 1809542 (view as bug list) Environment:
Last Closed: 2021-02-15 07:38:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Martin Kyral 2018-04-27 07:24:39 UTC
Description of problem:
Per documentation, the safe = 0 boolean shall make rmtree to delete even directories with insufficient permissions. However, with the 2.15 version from rh-perl526 SCl the boolean does not work and directories with insufficient permissions are left in place:


:: [ 03:13:12 ] :: [  BEGIN   ] :: Running 'ls -l access'
celkem 0
d---------. 5 filepathtester filepathtester 41 27. dub 03.13 no
drwxrwxrwx. 5 filepathtester filepathtester 41 27. dub 03.13 yes
:: [ 03:13:12 ] :: [   PASS   ] :: Command 'ls -l access' (Expected 0, got 0)
:: [ 03:13:12 ] :: [  BEGIN   ] :: Running rmtree() under regular user with safe = 1 :: actually running 'su filepathtester -c "perl -e 'use File::Path; File::Path::rmtree(\"access\", 1, 1)'"'
rmdir one
rmdir two
rmdir three
rmdir yes
cannot chdir to child for access/no: Permission denied at -e line 1.
rmdir access
cannot remove directory for access: Directory not empty at -e line 1.
:: [ 03:13:12 ] :: [   PASS   ] :: Running rmtree() under regular user with safe = 1 (Expected 0, got 0)
:: [ 03:13:12 ] :: [   PASS   ] :: File access/yes should not exist 
:: [ 03:13:12 ] :: [   PASS   ] :: Directory access/no should exist 
celkem 0
d--x--x--x. 5 filepathtester filepathtester 41 27. dub 03.13 no
:: [ 03:13:12 ] :: [  BEGIN   ] :: Running rmtree() under regular user with safe = 0 :: actually running 'su filepathtester -c "perl -e 'use File::Path; File::Path::rmtree(\"access\", 1, 0)'"'
cannot chdir to child for access/no/one: Permission denied at -e line 1.
cannot chdir to child for access/no/two: Permission denied at -e line 1.
cannot chdir to child for access/no/three: Permission denied at -e line 1.
rmdir no
cannot remove directory for access/no: Directory not empty at -e line 1.
rmdir access
cannot remove directory for access: Directory not empty at -e line 1.
:: [ 03:13:12 ] :: [   PASS   ] :: Running rmtree() under regular user with safe = 0 (Expected 0, got 0)
:: [ 03:13:12 ] :: [   FAIL   ] :: Directory access should not exist

Version-Release number of selected component (if applicable):
rh-perl526-perl-File-Path-2.15-2.el7

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Petr Pisar 2018-04-27 11:09:23 UTC
This seems to be caused by CVE-2017-6512 fix that's part of File-Path-2.13 release. Also our backport to 2.12 suffers from it.

Comment 2 Petr Pisar 2018-04-30 13:18:03 UTC
If a directory cannot be entered (chdir), the new code will open the affected directory for reading to obtain a file descriptor to pass it to fchmod() to change the directory's permissions to retry the chdir().

But in the reported case, the directory is missing a read permission (mode 0000), thus the open() fails and the code reports an error.

Obviously the code was written to deal with non-writable directories. Non-readable directories is the new issue.

Comment 8 RHEL Program Management 2021-02-15 07:38:43 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.