Piotr Karwasz created IO-878:
--------------------------------
Summary: 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
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)
