Ensure that FileManager.copyItem cannot copy directory metadata to files #1081
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
FileManager.copyItem(atPath:toPath:)
has a TOCTOU bug due to how it recursively copies directories. As we recursively copy directories, we copy the directory itself with default metadata/permissions, copy the contents of the directory, then copy the metadata over (which may change permissions on the directory, including potentially making it read-only). This TOCTOU bug allows another process with write access to the source directory to (with the right timing) cause a process that usesFileManager.copyItem
to copy and apply metadata to a file rather than a directory.To fix the TOCTOU issue, the post-order traversal which copies the metadata now:
fstats
the source and destination directories to validate that they are directories (and not files)fcopyfile
on Darwin, and a custom function on Linux wherefcopyfile
does not existThis ensures that we only copy metadata between directories and cannot accidentally apply metadata to a file.