site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Thanks very much, Bill. And thanks to Stephane for your input, as well. One thing I should mention is that I have found that the installer option to "Overwrite Directory Permissions" did not work when I tested it (we are using Iceberg 1.2.9 on 10.6.2, but I don't know where the bug lies), so we are resorting to fixing these issues in the preflight script for the daemon install. Bill, you bring up interesting issues around the idea of fixing the "/" directory owner, so now we have a dilemma that I will escalate to my manager. The thing is, it's an awful bad story when a problem like "/" having the wrong owner causes our whole install to fail, and the user doesn't know why (unless he knows to look at the log, where we emit useful information), and fixing permissions in DU won't help. We could put some instructions in our ReadMe to type some commands in Terminal... BTW, one of my contacts working on Disk Management will probably file the bug (Bill, you know who). We currently have decided to fix permissions anywhere in the path /Library/PrivilegedHelperTools/, and we would only touch the owner:group if owner is not "root," i.e., we don't check the group. My script currently sets ownership to root:wheel if the owner is not "root." Since we want to do this right, and we are running out of time, we are considering opening a DTS support incident. I appreciate everyone's contributions, but almost all of them have come with the caveat that "this is not a definitive answer." Thank you all, again. If we ask DTS, I will post their advice to the list. Monte On Aug 17, 2010, at 2:18 PM, Bill Coderre wrote:
On Aug 13, 2010, at 5:37 PM, Monte Benaresh wrote:
One of our installers installs a daemon to /Library/PrivilegedHelperTools/. I have written a bash script to enforce the security recommendations in TN2083, which says that this directory, and all of its parents, must have certain permissions and must be owned by "root" in order to prevent an unauthorized process from substituting their own daemon in place of ours.
Our problem is, one of our Beta users has "/" owned by "_spotlight", and so we fail to install due to the security checks in our preflight script as alluded to above. Disk Utility does not repair this problem.
Hi, Monte. I've been thinking about this off and on, so here's an informed opinion (ie. not an official rule, or even a tech note).
It is very unusual to have / owned incorrectly. (I don't think I've ever heard of it.) I suggest filing a bug against Disk Utility, since you say it's not fixing it.
Because this situation is very unusual, I've never seen an installer check for it, or attempt to fix it. Usually, permissions are managed by the file copying machinery used by Installer.app, and packages just allow the default behavior to happen.
We are concerned that this will be a support issue, so our questions are:
1. Can we securely allow "/" to be owned by other than "root"? I don't know. I'm not a security expert.
2. Is it permissible for us to change the owner of "/" to "root"? Although I might be tempted to let myself be convinced to have your installer just fix the problem since it's clearcut and simple, I'm of the opinion that it's a bad idea, if only because the name of the app is "Installer" and not "Disk Utility."
I'm a bit worried about unforeseen consequences, for one, and for another, I don't want people to get an idea that running some third-party installer will fix their problems. We still have people convinced that zapping the PRAM and rebuilding the desktop database is "routine maintenance."
Third reason not to do anything: I think it's a really rare problem. It might be literally just this one user. And if it's not, I'd rather not have your installer masking a problem.
3. If either /Library/ or Library/PrivilegedHelperTools/ is not owned by "root" is it permissible for us to change the owner to "root"?
In the past, I have fixed permissions to subfolders of /Library, when clients have specific bugs with a clear cause. I would be asking, "So why can't the app fix the permissions itself?"
I don't think I've changed /Library or /, but I can easily see an OS upgrade doing so. The usual case involves a policy change dictated by security issues. To make up an example, it might be OK to have a folder be root/admin/0775 on 10.5, but have it change to root/wheel/0755 on 10.6.
_______________________________________________ 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