Re: PackageMaker, Installer, and system folder permissions
Re: PackageMaker, Installer, and system folder permissions
- Subject: Re: PackageMaker, Installer, and system folder permissions
- From: "Louis C. Sacha" <email@hidden>
- Date: Fri, 20 Feb 2004 21:04:31 -0800
Hello...
The problem you are having sounds like the effects of a known
feature/bug in the 10.2 and previous versions of Apple's Installer
(aka the XInstall Framework). It's not entirely Apple's fault, since
part of the problem is the way the installer package is built by the
user (the developer who is making the package).
This hopefully should have been corrected/changed in the version of
Installer that shipped with 10.3, but I have not personally verified
it (the bug report I filed has a status of closed/duplicate, although
this might simply mean that my particular report was closed because
it was a duplicate... the original report is BugID# 3009442 if anyone
knows how to lookup bugs with the ID#). If you are running 10.3, and
you are still seeing this problem, you might want to file a bug
report of your own.
As I mentioned above, part of the problem might be the way that you
are creating your package.
First, in general you shouldn't need to chown/chmod stuff in the
postinstall script. Make sure that the permissions for the copy of
the kext you are using to build the package are correct (in other
words, with the ownership already set to root/wheel with the correct
permissions rwxr-xr-x). ***
If you are only installing the kernel extension, the easiest way to
avoid the problem that messes up ownership of existing folders is
just to specify the "Default Install Location" as the full path to
the extensions folder, so instead of "/", use
"/System/Library/Extensions/" for that path.
If you are installing things in multiple locations, then you can't
use a full path for the default install location, and need to use a
distribution heirarchy (which, based on the problem you are having, I
assume is what you are doing now). You need to make sure that the
folders you use to build the package have the correct permissions
that those folders should have on the destination disk:
For example, if you are making the distribution heirarchy for
foo.kext, and you are building it in a folder called distribution in
your user folder, you would have the heirarchy (including the full
path)
/Users/you/distribution/System/Library/Extensions/foo.kext
You need to make sure that the System, Library, and Extensions
folders in that heirarchy have the same ownership and permissions as
the real /System/Library/Extensions/ folders (ie root/wheel,
rwxr-xr-x).
Most people would expect that the permissions of existing folders
wouldn't be changed, but technically the Installer app is working the
way it is supposed to. So this problem is partly the design (which
may be counter-intuitive, but it is documented, although not in an
obvious "this is what will happen" way), and partly the user's
assumption about how the distribution heirarchy is used.
Hope that helps,
Louis
*** There are also a couple of install package flags that might
affect the permissions of the installed kext, although the most
likely reason is that the copy of the kext that the install package
was built with has the wrong ownership/permissions. It's been a while
since I used PackageMaker, but based on the info.plist file of an old
kext install package that works correctly, you might want to check
and make sure that the IFPkgFlagOverwritePermissions and
IFPkgFlagUseUserMask flags are both set to FALSE, which if I remember
correctly should be the defaults.
I am creating PackageMaker packages and running the installer to
install software that I want to distribute. I have noticed, though,
that when the installer runs it changes the permissions of
directories which it accesses.
My package installs a kernel extension into
/System/Library/Extensions. Kernel extensions need to be root:wheel
ownership, so I have a postinstall script that will do a "cd
/System/Library/Extensions; chown -R root:wheel <kextname>.kext".
I also have:
<key>IFPkgFlagAuthorizationAction</key>
<string>RootAuthorization</string>
In the package's Contents/Info.plist file.
However, I just repaired the permissions on my system, installed my
package and then verified the permissions again, and I have found
that the ownership on /System/Library/Extensions has been changed to
<myid>:staff.
Testing another package (an uninstaller), it seems that the target
folder for any installer package is changed to my owner and group.
Why is this happening? Is there a way to keep it from happening?
Thanks!
-Michael
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.