On Dec 29, 2006, at 4:46 PM, John Daniel wrote:
Just make sure your installer uses AdminAuthorization. Then, the postinstall scripts will be run with Administrator rights. The user will be asked for an administrator password before installing. You will not have to explicitly say "sudo" as you will already be administrator. That will solve your immediate problem. It will also create some new ones.
To be somewhat pedantic, if the script authorization level is set to AdminAuthorization or to RootAuthorization, scripts run as root -- this might make a difference. If you are installing stuff in sytem software areas, you'll probably want RootAuthorization anyway.
(Apple recently made AdminAuthorization identical to RootAuthorization in 10.4.8 and later, in response to requests from the security community, but the only difference before that change was that if the script was marked "AdminAuthorization" and the user was an admin, they did not have to authenticate. Now, if the script is marked either "AdminAuthorization" or "RootAuthorization", users must authenticate.)
Note that there are cases where you want to do things to each user's own files, for instance, change a user preference file. (Note: The correct answer is to go back to the software author and tell them to fix their own bugs, rather than rely on an installer to bail them out. Then again, that is not always possible.) In those cases, you need to run as the user in question. This prevents a class of security problems[1], and also avoids a bunch of potential permissions foul-ups.
After discussion amongst coworkers here at Apple, I ended up doing stuff in this way:
#!/usr/bin/perl
if (opendir(USERHANDLE, "/Users")) {
while (defined(my $USER = readdir(USERHANDLE))) {
next if $USER =~ /^\./;
next if $USER eq "Shared";
system("/usr/bin/su", $USER, "-c", "/bin/rm -rf \"/Users/" . $USER . $folder1ToDestroy ."\"");
}
}
# the current user might not be in /Users, if they have a net-based home directory
system("/usr/bin/su", $ENV{USER}, "-c", "\"/bin/rm -rf \"" . glob("~" . $folder1ToDestroy) . "\"");
exit 0;
I use su instead of sudo, because a handful of unix geeks force sudo always to ask for a password no matter what, and therefore sudo cannot be relied on in these cases.
You will have to make sure all of the files you install have the appropriate ownership and permissions. When run as Administrator, the installer will create files exactly as they are in the archive.pax.gz file. That mean that if they are owned by bweitzer when you create the installer, they will be owned by bweitzer on the user's machine. That is actually a slight exaggeration, but only slight. They files will have your user id which will "probably" work fine. Don't count on it though. Test, test, and re-test.
The latest incarnations of PackageMaker have settings to correct permissions. Although they require Leopard or Tiger, they make packages compatible back to 10.1.
[1] If your program is running as root, and touching files that could be created by a non-admin user, there is a potential security problem: Jacques Chapeau-Noir could create a symlink to a protected file, and your program could potentially damage that protected file. This is why it is a bad idea to install into /tmp, but the same goes for stuff in /Users.