Bug 1572500 - rmtree with safe = 0 does not work
Summary: rmtree with safe = 0 does not work
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: perl-File-Path
Version: rh-perl526
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.7
Assignee: perl-maint-list
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-27 07:24 UTC by Martin Kyral
Modified: 2021-02-15 07:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1584709 1809542 (view as bug list)
Environment:
Last Closed: 2021-02-15 07:38:43 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CPAN 122255 0 None None None 2018-04-27 11:15:53 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.