withBinaryFileDurableAtomic and similar override permissions set by user with fchmod()

[nh2]

When I do

withBinaryFileDurableAtomic "myfile" WriteMode $ \handle -> do
  
  fd <- handleToFd handle
  fm <- Posix.fileMode <$> Posix.getFdStatus fd
  Posix.setFdMode fd myPermissionsHere

  return x

then myPermissionsHere results in an fchmod(), but those permissions are later overridden by an fchmod() that unliftio does just before the file is closed.

Reason

withBinaryFileDurableAtomic does

      mFileMode <- copyFileHandle iomode filePath tmpFileHandle
      res <- action tmpFileHandle
      atomicDurableTempFileRename dirFd mFileMode tmpFileHandle mTmpFilePath filePath

where mFileMode = Nothing when copyFileHandle says that the file doesn't already exist (the normal case), and atomicDurableTempFileRename runs this:

        let fileMode = fromMaybe Posix.stdFileMode mFileMode
        -- work around for the glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17523
        Posix.setFdMode fd fileMode

This means that atomicDurableTempFileRename will always call setFdMode with stdFileMode, thus erasing any permissions the user may have set in action.

Proposed solution

We should call our setFdMode before res <- action tmpFileHandle is run.

---

CC @lehins

[lehins]

The only way the user can set permission in the action is by getting access to the Fd, like you did, which is not something that is supported by the API because it is not OS agnostic.

I do however realize why the functionality of setting file permissions atomically at the same time as file modification happens would be desired, especially since we already have the Fd opened.

We should call our setFdMode before res <- action tmpFileHandle is run.

The proposed solution does seem logical, but I am afraid it will require some restructure of current code, since access to Fd right from the start was not designed to be provided to the user.