You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gary D. Gregory (Jira)" <ji...@apache.org> on 2021/09/26 17:30:00 UTC

[jira] [Comment Edited] (IO-751) When deleting symlinks, File/PathUtils.deleteDirectory() changes file permissions of the target

    [ https://issues.apache.org/jira/browse/IO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420340#comment-17420340 ] 

Gary D. Gregory edited comment on IO-751 at 9/26/21, 5:29 PM:
--------------------------------------------------------------

Hm, now I'm thinking that the following is more appropriate:
{noformat}
diff --git a/src/main/java/org/apache/commons/io/file/PathUtils.java b/src/main/java/org/apache/commons/io/file/PathUtils.java
index 9d65243..f9968c2 100644
--- a/src/main/java/org/apache/commons/io/file/PathUtils.java
+++ b/src/main/java/org/apache/commons/io/file/PathUtils.java
@@ -1169,6 +1169,9 @@
             // java.lang.IllegalArgumentException: 'unix:readonly' not recognized
             final PosixFileAttributes readAttributes = posixFileAttributeView.readAttributes();
             final Set<PosixFilePermission> permissions = readAttributes.permissions();
+            permissions.add(PosixFilePermission.OWNER_READ);
+            permissions.add(PosixFilePermission.GROUP_READ);
+            permissions.add(PosixFilePermission.OTHERS_READ);
             permissions.remove(PosixFilePermission.OWNER_WRITE);
             permissions.remove(PosixFilePermission.GROUP_WRITE);
             permissions.remove(PosixFilePermission.OTHERS_WRITE);
 {noformat}
But this is mostly orthogonal to the delete directory and symlink APIs issues you raised.


was (Author: garydgregory):
Hm, now I'm thinking that the following is more appropriate:
{noformat}
diff --git a/src/main/java/org/apache/commons/io/file/PathUtils.java b/src/main/java/org/apache/commons/io/file/PathUtils.java
index 9d65243..f9968c2 100644
--- a/src/main/java/org/apache/commons/io/file/PathUtils.java
+++ b/src/main/java/org/apache/commons/io/file/PathUtils.java
@@ -1169,6 +1169,9 @@
             // java.lang.IllegalArgumentException: 'unix:readonly' not recognized
             final PosixFileAttributes readAttributes = posixFileAttributeView.readAttributes();
             final Set<PosixFilePermission> permissions = readAttributes.permissions();
+            permissions.add(PosixFilePermission.OWNER_READ);
+            permissions.add(PosixFilePermission.GROUP_READ);
+            permissions.add(PosixFilePermission.OTHERS_READ);
             permissions.remove(PosixFilePermission.OWNER_WRITE);
             permissions.remove(PosixFilePermission.GROUP_WRITE);
             permissions.remove(PosixFilePermission.OTHERS_WRITE);
 {noformat}

> When deleting symlinks, File/PathUtils.deleteDirectory() changes file permissions of the target
> -----------------------------------------------------------------------------------------------
>
>                 Key: IO-751
>                 URL: https://issues.apache.org/jira/browse/IO-751
>             Project: Commons IO
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 2.11.0
>         Environment: macOS 11.5.2
> OpenJDK 11
>            Reporter: Richard Cyganiak
>            Priority: Major
>         Attachments: DeleteDirectoryTest.java
>
>
> When {{FileUtils.deleteDirectory(...)}} and {{PathUtils.deleteDirectory(...)}} encounter a symlink while recursively deleting, the default behaviour is to delete the symlink, but leave the target of the symlink alone. This works for the most part: the symlink is correctly deleted, and the target is not deleted or recursed into.
> However, the methods _alter the file permissions of the target_:
> - {{FileUtils.deleteDirectory(file)}} _removes_ all write permissions from the target
> - {{PathUtils.deleteDirectory(path, StandardDeleteOption.OVERRIDE_READ_ONLY)}} _removes_ all write permissions, and _adds_ all execute permissions (even if the target is a file, not a directory)
> - {{PathUtils.deleteDirectory(path)}} works correctly and does not change the target's permissions
> A JUnit 4 test case that demonstrates the behaviour of all three methods is attached.
> The behaviour is unexpected (the Javadocs give no hint), inconvenient (it leaves the owner of the target without write permission) and potentially dangerous (it adds execute permissions for anyone).
> It appears the implementation assumes it can freely modify permissions because it is going to delete the file/directory anyway, and the case of symlinks was simply not considered. The handling of write permissions is particularly puzzling. I could understand  why an implementation would _add_ write permission, but why _remove_ it?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)