Re: Permissions checks when installing a daemon
Re: Permissions checks when installing a daemon
- Subject: Re: Permissions checks when installing a daemon
- From: Bill Coderre <email@hidden>
- Date: Tue, 17 Aug 2010 14:18:47 -0700
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden