When I delete caches to the TRASH and then try to "securely delete" using PERMANENT ERASER or ONYX (Sierra), I get a message about . . .
. . . cannot be deleted (something about incompatible?).
Anything I should be concerned about? Should this file be removed by some other method?
Any help would be appreciated.
That's interesting, I'll have to go look for that. (where is that file located?)
Unix filesystems have ownerships, ACLs, permissions, and flags for security. Mac OS's older HFS (a la mac os 8 and 9) used a bit for indicating a file was locked. Unix has a flag that was suitable caned UCHG. (user unchangeable) OS X used that flag for the new HFS+ system.
There is another lock flag you don't see much. In the past it's only been on ONE file on the entire computer. The kernel booter. /System/Library/CoreServices/bootx (or Boot.efi for PPC)
That file is protected by a "super lock", SCHG. (system unchangeable) Only root can add or remove it, but there's an added catch. Once the system has elevated from kernel protection level 0 to 1 (early in the boot process) SCHG cannot be removed. 0->1 is a one-way trip, so to return to level 0 requires a reboot. So to remove it, you have to boot into single user mode and remove it via terminal. This prevents a truly nasty virus from infecting the bootstrap process and making a rootkit. The firmware is very well guarded, and the kernel does signature verification on itself and all privileged binaries, but the kernel booter is protected only by some crypto and that flag. That prevents malware from easily replacing it, even if it can find a hole in the security or con the user into giving up the password. See also "(boot) chain of trust". (firmware -> booter -> kernel -> os)
I suspect a variation on this theme is being used for "rootless" mode, where not even root can mess with certain file structures. BTW, I hate that. I understand why they're doing it, but I still hate it. I hate it less knowing I can turn it off. The day I can't turn it off the hate will get much deeper. And knowing Apple, that day will come.
Aaaaanyway, that filename is reminiscent of SCHG, and the prefix "SUID" is another flag that allows an app to run under the privileges of the owner of the file, instead of the person running the file, so again that one needs to be protected well usually. SUID is often used to create back doors for apps that need helpers, so that the app can be run by an unprivileged user but do privileged things. (theres another active thread on this topic I replied to just a little while ago)
Alexandria Librarian's client installed a library reader for the school's library that had a SUID file. Wisely, apple's disk image restore process did not restore that flag, but unfortunately that required an admin password on the first launch to fix it... on every imaged computer in the library. yay.