site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=UVtbNJa9TkMxN4jHfPztAHYiHiPv8l9RUPhXkWZ10yQ=; b=BLVXKXwd0D4ghuqZEkw84u6W42v9vHmF/o8joAhpJSMPQuEqmmnngHkltIqwWGdgV0 DfSsU2mj94jma6rF7IQs3e1zFXMvFvL9mamFx76PlDuzJZuAe6Rl4D92Htfjb31Iafil pEBSNgiWG56LgCwL0TA287R2GU4LzAq3SXtq0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=TMZFSXgKGhkHcHvOwYg8ki2smB1IHvULR7sp2LWvhTkm2MiepiZw+RMmxud8UXzKNN BXeev/UbryZ5oAxY70fs3REaDVPtGLEzBsgO/Dh7ZkNB/Pf27U63jxTC95vNFyvBssgg 4o7ERGckGGbF6ZptX+HXlFaj5L+YVzM/rawCg= On Apr 3, 2009, at 4:05 PM, Rick Mann wrote: installer -pkg PATH/TO/your_package.pkg -target /tmp/TEMPFOLDER/ -- Karl Kuehn larkost@softhome.net _______________________________________________ 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... I am combining your two questions into one response, because I tried to answer one of your questions in the post you quoted in the other question. But if you are going to need root permissions to update things, then don't you need it during the install? And if so, then if you put in a postflight script it should run as root already (script or program), solving your problem. It occurs to me...how do pre- and post-flight scripts get to do privileged operations during installation? Or can they not? That was the whole point of my comment: if your installer has the run- as-admin/root flag checked it will call the postflight script with root permissions, so you don't have to use setuid at all. However, I am going to urge you to think this through, there are two cases you should make sure that your installer (and by extension now your updater) takes into consideration: 1) The installer could be run via something like Apple Remote Desktop and be running either underneath a totally unaware user, or it could be running behind the loginwindow. Both of these circumstances mean that you should not have any GUI component that is not part of the normal installer system (ie: installer bundles). 2) Your installer could be run on a filesystem other than the booted one, even if you have set the "only on booted volume" flag. This is used internally by Apple in packaging computers (for special runs), and projects like InstaDMG also do this. I'm not sure of the impact you're cautioning me about in these two instances. It should never run behind the login window, because we don't launch the agent unless the user is logged in. But you might be launching your updating routine behind the login window (or in other silly circumstances) if you call it in a postflight script. My point is to break installer writers of the assumption that they are always writing for the same environment that they are developing in. Don't get #2 at all. With InstaDMG it creates a whole OS install on a DMG from a series of .pkg's. The command line version of the installer is used something like this: Where TEMPFOLDER is the mount point for the .dmg that is being installed to. My point here is that even if you set the flag to only allow your package to be installed to "root" that my script walks right through that and your software will be installed at the root of the dmg mounted at /tmp/TEMPFOLDER/. This works great except that when an installer post-flight script comes along and writes things to "/", where there might be no version of that software installed at all. So my point is to use the target root that the installer passes to the postflight at $3 as your target. In most cases this will wind up evaluating to "/", but in some cases it will not. This email sent to site_archiver@lists.apple.com