In 2 different cases, people are reporting that installing stuff in /usr/local/share/man is not working on macOS 10.13.3 systems (with supplemental updates).
In each case:
- the items are installed through a .pkg installation package (like the ones produces by pkgbuild).
- the install.log file reports that shove is not able to change the flags of a file in /usr/local/share/man/man8 or of the folder /usr/local/share/man/man8 because the item does not exist:
shove[795]: [src=unknown] /usr/local/share/man/man8: unable to restore flags to destination (error 2)
shove[795]: [source=dir, dst=notExist] failed _RelinkFile(/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/PKInstallSandboxManager/F687D242-3522-4905-8EBF-3FFA3791F411.activeSandbox/Root/usr/local/share/man/man8, /usr/local/share/man/man8): Operation not permitted
shove[795]: srcPath = /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/PKInstallSandboxManager/F687D242-3522-4905-8EBF-3FFA3791F411.activeSandbox/Root/usr/local/share/man/man8 NSFileOwnerAccountID=0 NSFileSystemFileNumber=8607927104 NSFileExtensionHidden=0 NSFileSystemNumber=16777220 NSFileSize=192 NSFileGroupOwnerAccountID=0 NSFileOwnerAccountName=root NSFileCreationDate=2018-01-24 10:51:49 +0000 NSFilePosixPermissions=493 NSFileType=NSFileTypeDirectory NSFileGroupOwnerAccountName=wheel NSFileReferenceCount=6 NSFileModificationDate=2018-03-07 19:57:48 +0000
shove[795]: dstParentPath = /usr/local/share/man NSFileOwnerAccountID=0 NSFileSystemFileNumber=9053 NSFileExtensionHidden=0 NSFileSystemNumber=16777220 NSFileSize=160 NSFileGroupOwnerAccountID=0 NSFileOwnerAccountName=root NSFileCreationDate=2013-02-05 17:04:12 +0000 NSFilePosixPermissions=493 NSFileType=NSFileTypeDirectory NSFileGroupOwnerAccountName=wheel NSFileReferenceCount=5 NSFileModificationDate=2018-03-07 19:52:22 +0000- when the man8 folder exists in /usr/local/share/man/, it's because it has been created/shoved by the installation package but later on, the folder can not be removed even using sudo rm -r . It fails with "Operation not permitted".
- as far as I can tell, there are no specific ACLs set on the man folder and its close ancestors.
- as far as I can see, there are no "com.apple.rootless" extended attribute set on /usr/local and the other subfolders.
- the user accounts running the sudo rm -r command are part of the admin group and the /etc/sudoers file looks fine.
- the installation or removal works fine on other computers running the same OS versions.
Running out of obvious explanations, it makes one wonder whether the issue does not involve SIP.
Question:
Is there a known issue with SIP on macOS 10.13 where its protection would unexpectedly extend deeper than /usr?
