site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com <installer-dev-bounces+xochitl_lunde=tripplite.com@lists.apple.com> wrote on 08/19/2010 02:34:29 PM:
Hi All,
I don't mean to beat a dead horse, but we are close to deciding what
to do when our preflight script finds wrong permissions or owner
when checking /Library/PrivilegedHelperTools/ and it's parents.
Here are the remaining questions we have boiled down to:
1. Should we just aspire to the same degree of permissions/owner
repair that Disk Utility does, i.e., not care about the owner on
"/"? BTW, DU does not fix a bad owner or permissions of
/Library/PrivilegedHelperTools/. I know some of you have said that
DU should fix the owner of "/".
2. If the user's system already has permissions/owner settings that
are insecure, are we creating any additional insecurity by
installing a daemon into a structure that is already compromised?
Do we have a responsibility, as a third-party software installer, to
fix this situation?
Thanks for your input. We will make our decision this evening, Pacific time.
Regards,
Monte Benaresh
PACE Anti-Piracy
The only similar sounding apple code that I have seen is in a unix domain socket example. It doesn't come with an installer, but it does do a permission check on the directories where the unix domain socket resides. If the permissions are wrong, this Apple program refuses to run. (Server.c: ). The documentation in source code for unix domain sockets matches the recommendation for daemons in TN2083 about owners & permissions. Even if you fix the weird user with the installer, what's to say that it won't just happen again after you've installed? I don't know what your daemon does, but if you're concerned about the security of the file system, wouldn't this be a check your app should run whenever it starts? If your daemon is checking the security on startup, then your installer probably does not have to do anything. Rather than designing a strange installer, have you thought about packaging a "fix it" script with your distribution instead, if you really think a lot of people will have this problem? i.e. : Install fails with message about running fix it tool.. user runs fix it tool from DMG. If the user has to start running the fix it tool a lot, it becomes apparent something is messing with his file system in an undesirable way. I just looked at TN2083 again. To me it seems like they've made updates that weren't noted, but probably my memory is failing.