Re: More on daemon install and permissions/owner checks
Re: More on daemon install and permissions/owner checks
- Subject: Re: More on daemon install and permissions/owner checks
- From: Xochitl Lunde <email@hidden>
- Date: Thu, 19 Aug 2010 16:32:20 -0500
<installer-dev-bounces+xochitl_lunde=email@hidden>
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. http://developer.apple.com/mac/library/samplecode/CFLocalServer/Introduction/Intro.html
(Server.c: SafeBindUnixDomainSocket).
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.
_______________________________________________
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