[
https://issues.apache.org/jira/browse/IO-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039992#comment-18039992
]
Gary D. Gregory commented on IO-878:
------------------------------------
We need to keep a broader context in mind for this change: Cleaning and
deleting files and folders from the call sites of PathUtils.setReadOnly().
For example, the classes CleaningPathVisitor, DeletingPathVisitor, and the
PathUtils methods that use these visitors. As long as these work and the output
is unsurprising, I think we will be OK.
> Fix `PathUtils.setReadOnly` behavior on POSIX platforms.
> --------------------------------------------------------
>
> Key: IO-878
> URL: https://issues.apache.org/jira/browse/IO-878
> Project: Commons IO
> Issue Type: Bug
> Reporter: Piotr Karwasz
> Priority: Minor
>
> The current implementation of {{PathUtils.setReadOnly}} does not behave
> correctly on UNIX-like systems:
> * Since Java 9 (with the introduction of {{LinuxDosFileAttributeView}}), the
> method is effectively a no-op: it toggles an extended file attribute that is
> not enforced by the OS for access control. This is the main cause of the
> failure of {{DeleteDirectoryTest}} on Linux.
> * On filesystems *without* extended attributes, it attempts to adjust parent
> directory permissions. As a result, calling {{setReadOnly(false)}} not only
> makes the target file writable, but can also make the directory inaccessible,
> affecting all files within and creating unexpected security issues.
> This method conflates two distinct effects of the legacy DOS read-only flag
> on Windows:
> # Prevent opening a file for write access.
> # Prevent deletion (and thus replacement) of the file.
> *Why this is problematic*
> * The JDK’s own {{File.setReadOnly}} only models the *first* effect (blocks
> write-open), not the deletion semantics.
> * Changing directory permissions to approximate DOS semantics has unintended
> side effects on unrelated files and users.
> *Proposal*
> Revise {{PathUtils.setReadOnly}} to align with one of two clearer semantics:
> # *Follow the JDK model*: only toggle the file’s owner write bit on POSIX.
> # *Restrict to DOS semantics*: treat the method purely as a wrapper for
> {{DosFileAttributeView.setReadOnly}}.
> Both approaches are valid, since the current Javadoc deliberately leaves the
> exact semantics system-dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
