Re: setuid installer?
Re: setuid installer?
- Subject: Re: setuid installer?
- From: Karl Kuehn <email@hidden>
- Date: Fri, 3 Apr 2009 16:51:08 -0700
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.
On Apr 3, 2009, at 4:05 PM, Rick Mann wrote:
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:
installer -pkg PATH/TO/your_package.pkg -target /tmp/TEMPFOLDER/
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.
--
Karl Kuehn
email@hidden
_______________________________________________
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