Setting the umask needed to get 0644 perms on a plist file runs the risk of inadvertently granting those same elevated permissions to other installed files that should not have them. Wouldn’t it be more reliable and secure to have the default perms be 0600 (as they are) and only grant more permissive permissions explicitly where needed on a case by case basis?
And that leads directly to LaunchDaemon plist files being such a case. Having 0600 permissions on them is simply wrong. I’ve done further digging and conversed with several Apple engineers about it. Here’s some of what I found:
Apple’s SMJobBless function “obviates the need for a setuid helper invoked via AuthorizationExecuteWithPrivileges() in order to install a launchd plist”. Guess what permissions that function sets on the plist file it installs (regardless of the calling umask)? 0644, just like all of Apple’s other LaunchDaemon plists.
The readme from Apple’s stalwart BetterAuthorizationSample sample Xcode project shows:
/Library/LaunchDaemons/.plist rw-r--r-- root:wheel
and goes on to say “This is the standard location, name, and permissions for launchd configuration files”.
I asked a current Apple engineer (Keith Stattenfield) why launchd accepts plist files with 0600 permissions if they aren’t right. There were two parts to his response.
— 1 —
launchd is not the only process that reads the plist files:
“Various other bits of the system besides launchd also read the launchd job files, for both administrative and auditing purposes. Some of these daemons are running as role users, and having a launchd job file which is not world readable will make these daemons fail.
Speaking unofficially for Apple, but with some authority as the author of one of those system daemons.”
— 2 —
launchd only rejects excessive permissions like world write that would cause it to be a security risk. It is not launchd’s function to attempt to know or enforce the plist permission requirements of other processes. Thus expecting launchd to reject a plist file that lacks world-read needed by something else is not valid.
I see no legitimate reason why Homebrew should not explicitly install these plist files with the permissions Apple clearly intends for them to have.