[
https://issues.apache.org/jira/browse/IO-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18024280#comment-18024280
]
Piotr Karwasz commented on IO-878:
----------------------------------
The {{fix/read-only}} branch contains some partial work to restore the
{{setReadOnly}} method on modern Linux platforms.
> 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)