RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS [v3]

David M. Lloyd duke at openjdk.org
Mon Oct 28 13:07:28 UTC 2024


On Fri, 25 Oct 2024 16:58:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>> 
>> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add bug ID to test
>  - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

Looking at related bug history, https://bugs.openjdk.org/browse/JDK-8214078 was considered a Bug not an Enhancement. What is the distinction? Is it due to being supported on other architectures on the same OS versus being unsupported by OS?

Another question I had was: does this being an Enhancement affect backportability?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2441532398


More information about the nio-dev mailing list