I have done the following
Steps to reproduce
The syscall behaviour can be reproduced independently of the archive reader:
- Create and open a regular file.
- Call
fchmod(fd, 0o6755).
- Call
fchown(fd, getuid(), getgid()).
- Call
fstat and inspect st_mode & 0o7777.
On Darwin, step 3 clears the set-user-ID and set-group-ID bits, so the resulting mode is 0755.
The same ordering exists in ArchiveReader.setFileAttributes: it calls fchmod before fchown. Once the full permission mask from #818 is restored, this archive-specific regression demonstrates the defect:
-
Write a regular archive entry with mode 06755, owner getuid(), and group getgid().
-
Extract it with ArchiveReader.
-
Read the extracted file's .posixPermissions.
-
Run:
swift test --disable-automatic-resolution -Xswiftc -warnings-as-errors --filter preserveSpecialPermissionBits
The test fails with:
Expectation failed: ((setIDPerms & permMask) -> 493) == (0o6755 -> 3565)
Set-ID permission bits should be preserved after ownership
Current behavior
ArchiveReader.setFileAttributes applies the archived mode and then changes ownership. Darwin's fchown clears set-user-ID and set-group-ID bits, including when ownership is set to the current UID and GID.
The issue is currently masked earlier by #818 because current main also truncates archive permissions to 0o777. It remains an independent defect in the stock main syscall ordering and becomes observable as soon as the full permission mask is restored.
Expected behavior
Archive extraction should set ownership first and apply the archived 0o7777 permission mode last, so the final extracted mode matches the archive entry.
Environment
- OS: macOS 26.5.1 (25F80)
- Xcode: 26.6 (17F113)
- Swift: Apple Swift 6.3.3
- Containerization source:
apple/containerization main at 50f77222964ed3d01dcb53f803ea2d511656a9dc
Relevant log output
Test preserveSpecialPermissionBits() recorded an issue at ArchiveReaderTests.swift:484:9
Expectation failed: ((setIDPerms & permMask) -> 493) == (0o6755 -> 3565)
Set-ID permission bits should be preserved after ownership
Test run with 1 test in 1 suite failed with 1 issue.
Code of Conduct
I have done the following
apple/containerizationmainat50f77222964ed3d01dcb53f803ea2d511656a9dcSteps to reproduce
The syscall behaviour can be reproduced independently of the archive reader:
fchmod(fd, 0o6755).fchown(fd, getuid(), getgid()).fstatand inspectst_mode & 0o7777.On Darwin, step 3 clears the set-user-ID and set-group-ID bits, so the resulting mode is
0755.The same ordering exists in
ArchiveReader.setFileAttributes: it callsfchmodbeforefchown. Once the full permission mask from #818 is restored, this archive-specific regression demonstrates the defect:Write a regular archive entry with mode
06755, ownergetuid(), and groupgetgid().Extract it with
ArchiveReader.Read the extracted file's
.posixPermissions.Run:
swift test --disable-automatic-resolution -Xswiftc -warnings-as-errors --filter preserveSpecialPermissionBitsThe test fails with:
Current behavior
ArchiveReader.setFileAttributesapplies the archived mode and then changes ownership. Darwin'sfchownclears set-user-ID and set-group-ID bits, including when ownership is set to the current UID and GID.The issue is currently masked earlier by #818 because current
mainalso truncates archive permissions to0o777. It remains an independent defect in the stockmainsyscall ordering and becomes observable as soon as the full permission mask is restored.Expected behavior
Archive extraction should set ownership first and apply the archived
0o7777permission mode last, so the final extracted mode matches the archive entry.Environment
apple/containerizationmainat50f77222964ed3d01dcb53f803ea2d511656a9dcRelevant log output
Code of Conduct