Bug 1572500 - rmtree with safe = 0 does not work
Summary: rmtree with safe = 0 does not work
Keywords:
Status: ASSIGNED
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.6
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: 2020-05-05 07:41 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:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
CPAN 122255 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.


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