FileManager posixPermissions effective mode across Apple SDK and Foundation on Linux

Question

Goal: create directories and files with restrictive POSIX permissions using Foundation FileManager so other local users cannot read them by default.

The effective mode depends on both FileAttributeKey.posixPermissions and the process umask at creation time. FileProtectionKey adds runtime data protection on Apple platforms, but availability differs across macOS, iOS, iPadOS, tvOS, watchOS, and Foundation on Linux. It is unclear whether attributes apply before the item becomes visible to other processes or sync extensions, and whether callers must capture and restore umask around creation calls without affecting other threads.

Assumption: the code targets multiple deployment targets, including an Apple SDK release and a Linux Foundation port, and cannot assume identical default modes.

Does FileManager apply posixPermissions before another process or sync extension can read the item?
Should callers manage process umask explicitly when targeting both Apple SDKs and Foundation on Linux?
Which FileProtectionKey values exist on each deployment target, and do they replace POSIX permissions?

Tasadduq Burney · Answer

Direct answer
FileManager applies posixPermissions as a mask against the process umask at creation time; the effective mode is never more permissive than requested. For directories, createDirectory applies the attribute atomically to the final path, but intermediate directories receive default permissions. For files, createFile is not guaranteed to apply permissions atomically—on some platforms and Foundation versions the file may be created with a default mode and then adjusted afterward, creating a brief window where other users could read it. FileProtectionKey is orthogonal: it controls encrypted-at-rest behavior on iOS, iPadOS, tvOS, and watchOS, but is unavailable on macOS and Linux, and it does not replace POSIX permissions.

Confirmed behavior vs. likely explanation
Confirmed: the effective mode equals requested permissions masked by umask. createDirectory with .posixPermissions sets the final directory's mode atomically. FileProtectionKey availability is platform-specific and excludes macOS and Linux.
Likely / verify locally: createFile may not apply permissions atomically. swift-corelibs-foundation on Linux follows POSIX semantics, but the exact timing of the permission change relative to file creation should be verified against the specific Foundation version.

Steps for cross-platform restrictive creation

Create items inside a parent directory that is already restricted to the current user (for example, mode 0o700). This eliminates the cross-process visibility problem without touching umask.
For directories, pass .posixPermissions to createDirectory; the final directory is protected atomically.
For files, after createFile returns, read back attributesOfItem(atPath:) and compare with stat to confirm the effective mode. If the parent directory was not already restricted, assume a race window exists.
Do not temporarily modify the process umask. It is process-global and not thread-safe; concurrent threads creating files would inherit the changed value.
On Apple mobile targets, add .protectionKey only if you need locked-device encryption; select the case available on your minimum deployment target. On macOS and Linux, rely solely on POSIX modes.

One missing detail
Is the parent directory already restricted to the current user? If yes, the createFile race window is contained and no further action is needed. If no, and the parent is world-readable, create the file in a temporary restricted subdirectory and then move it into place, or verify the specific Foundation version's createFile implementation.

FileManager posixPermissions effective mode across Apple SDK and Foundation on Linux

1 answer

Direct answer

Confirmed behavior vs. likely explanation

Steps for cross-platform restrictive creation

One missing detail

Your perspective belongs here.

1 question comment