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:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=w3Hm2fuyBGbJqfq8BNxvSjeWurHrThXz5FKOSxShtaI=; b=AElfMBI2q3ZGVE9lUMTdMoapefk7G5zedTnyhaZEQtE5mfG1JWkrGkaUHURViO1V9y VtGSqlh1quCW/5dGV57wnHyJARR9LFcKUioIpyUbNAg2/uZSEmoofH/MflKzjg3O627G b3af5sIqQxRSvhzLDCnoShWVFWe2aT9wQIneE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=o4b4XfmpMSAuOinlggYXQ1ldIEcEGtfywo8yD59/tuNZRUfsGfCEv9ujc17YhvBwtm 2Qu/PlnKq/hjp3GGxYiOUqCC7JS0srDi58b3TodhAjg9rr9e4UqoqPFes4R6bx7fntAh 11HtyEbJo7QV9iujebgX7JLQQk66GAn1EX73g= On Jun 23, 2009, at 4:34 PM, Peter Lee wrote: Eli _______________________________________________ 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... Thanks for the info! As a Mac OS X systems administrator, I find software that modifies files inside its own application bundles evil, and would encourage you to rethink that design decision. It makes it extremely difficult to store out malicious modifications from benign modifications. We're really not wanting to modify files inside the bundle... but we are deploying an embedded database server (Firebird) inside the bundle, that needs read / write access to it's security database when it runs. Security actually isn't used for the embedded version... but regardless - it needs the access! I guess it might be possible to put the database files in /Library/Application Support/Rising Software as well? Yes, this would be the thing to do. Create (or copy a default version from your bundle) this security database to /Lib/AppSupport/RS/. The permissions you put on the file depends on who can update the file and when it gets updated. I'd also urge you to consider making the file in /Library/ Application Support/Rising Software read-only, and copying it to ~/ Library/Application Support/Rising Software, where you can modify it in the user's home dir, but this is a matter of preference as long as the software can run with the /Library/Application Support/ Rising Software file missing or damaged by the user. The file in /Library/Application Support/Rising Software needs to be shared amongst all users - it's a shared database of settings, scores etc. If _anybody_ who runs the software must have read/write access to these files, you must set the mode to 666 if they are actually files, and 777 if they are directories. You _cannot_ rely on all users being in any specific group. Ahh... ok... thanks for this. Just looking in Packagemaker - how does one achieve this? Is it something best done with a post install script? If you install the file as part of your package, you generally should have the correct permissions on the file when you add it to the package. If you create or copy the file when your app is first launched, then you would use code to set the file permissions how you want them. This email sent to site_archiver@lists.apple.com