RFR: 8343020: SecureDirectoryStream not supported on MacOS

[David M. Lloyd]

On Thu, 24 Oct 2024 21:54:55 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.

After a lot of `printf` I'm closer to a diagnosis/solution:

* `fdopendir` is returning a valid pointer
* `readdir0` is using the same pointer, so nothing is being lost there
* `readdir` is returning entries which appear to be 4-byte aligned, so I think that's valid
* However the `dirent`'s `d_name` field is consistently offset by 15 bytes, which is kind of weird (but not really, because `char` usually has one byte alignment), and that does seem to be the correct struct member offset
* And, the first character of the directory name is definitely there, but at offset -1 from `d_name`, which is definitely screwy
* So what's the common thread? A test program using `fdopendir` works fine. But: if I load `fdopendir` using `dlsym`, now I have the off-by-one problem. So perhaps we're somehow getting a wrong or broken `fdopendir`. Further testing being done.

I'm getting close!

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

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