I'm guessing the endpoint application's propert list file should be installed in
/Library/LaunchDaemons
What about the actual endpoint program? I was leaning towards
/usr/libexec
but I haven't been able to find any guidance online for 3rd party daemon locations on the Mac.
Opps, title should be "Endpoint directory location", not "extensions".
I fixed that for (hope you don’t mind :-).
I haven't been able to find any guidance online for 3rd party daemon locations on the Mac.
The only official guidance I’ve seen is in the
hier/usr/local/******That assumes that you want the item ‘hidden’. If you want the user to be able to see your stuff, use
/Library/Application Support/***Warning Make sure that the directory and all of its parent directories and only writable by root. Specifically, do not place privileged code inside an app bundle because
/Applications/Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"Opps, title should be "Endpoint directory location", not "extensions".
😕
That is an Apple SIP location. You can't install there. Ideally, install it inside some application bundle.
Opps, title should be "Endpoint directory location", not "extensions".
I fixed that for (hope you don’t mind :-).
I haven't been able to find any guidance online for 3rd party daemon locations on the Mac.
The only official guidance I’ve seen is in the
hier/usr/local/******That assumes that you want the item ‘hidden’. If you want the user to be able to see your stuff, use
/Library/Application Support/***Warning Make sure that the directory and all of its parent directories and only writable by root. Specifically, do not place privileged code inside an app bundle because
/Applications/Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"I generally recommend that you create a directory called /usr/local/***, where *** is some name that identifies your company or your product, and install everything within that.
On a Mac, /usr/local is generally only used by open-source apps ported from Linux, including a number of "ports" packages. As such, it isn't a reliable location. It regularly gets corrupted or deleted. Because none of those other apps in /usr/local typically include uninstallers, most users will have to delete everything under /usr/local, including the OP's app, to uninstall some other 3rd party tool. I'm not sure if an "***" subdirectory would be enough to save the app.
That assumes that you want the item ‘hidden’. If you want the user to be able to see your stuff, use
./Library/Application Support/***
The /Library directory is also hidden. An Application Support path would be more reliable, but this makes for a more difficult uninstaller. Also, because this location is hidden, end users often don't know parts of the app are in there. If they need to reset the system (without restore from backup), the app will need to be reinstalled.
Make sure that the directory and all of its parent directories and only writable by root. Specifically, do not place privileged code inside an app bundle because /Applications/ is writable by admin.
Anything that isn't under SIP is writable by admin. They might have to authenticate or use sudo, but they can still write to it. Filesystem permissions are not secure and are vulnerable to modification or corruption by anyone who gains privileges. And end users hand over their admin passwords to anonymous, 3rd party developers like candy, so it is safe to assume anyone else in the world effectively has sudo privileges on the end user's system too. It would be better to just check the signature of the app bundle and refuse to run it if has been modified. Even this is hackable, but much more difficult.
The
directory is also hidden./Library
You are mistaking
/Library~/LibraryThey might have to authenticate or use sudo, but they can still write to it.
Right. This is a difference between an authenticated privilege escalation and an unauthenticated one. The latter is my concern.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"