Packagemker issue

If this is something that is entirely self-contained in the folder and doesn't require root to install, I'd probably go with distributing in a zip or dmg file rather than a package. Packages might make installs seem slicker, but the reality is that packages are the easiest vector for malware into the system. Especially when the entity putting together the package doesn't have the money to get it properly signed. With a bit more effort, most apps can be designed and implemented so you don't even need to distribute anything outside the bundle (include the docs in the bundle and accessible from the Help menu, register as a viewer for any plugin file types so a user can double-click a plugin and have it auto-copied to the right place, etc).

That said... the issue you are hitting is related to the permissions in your folder root as you are building the package. PackageMaker mirrors the permissions as they are seen on your own system, so you have to make sure the permissions are correct on your local filesystem before the package will produce correct ones.

 

So you are expecting PackageMaker to generate a folder for you that doesn't exist on the target system, and isn't part of the content you are installing either? At that point, PackageMaker doesn't have any real way to figure out what permissions you want set on the folder, so it uses "mkdir -p" or some equivilent on the path to install the app into. Because of that, you get default permissions which is read-only for group and everyone.

When you need more fine grained control, you need to make more of your install root 1:1 with the final appearance on disk. That way permissions for your pieces are controllable.

So instead of:
/My Projects/My App/Builds/My App.app -> /Applications/My Company Name/My App Name

You need something more like:
/My Projects/My App/Builds (Processed)/My Company Name -> /Applications

Where you have "./My App Name/My App.app" underneath "My Company Name".

There are install targets/steps you can configure and run in an XCode project to generate this layout automatically for you. Once you do that, you can use Package Maker to adjust the permissions on those folders since it is now part of the installed content. Multiple packages writing to this structure won't have an effect on each other. Another option is to fix the permissions in a postflight script.

EDIT: You have to keep in mind Package Maker has evolved considerably since the 10.0 days, where you literally had to replicate the parts of the system structure you installed into in your package. But things like this are hold-overs from those days. There was a point you couldn't even edit the permissions from within Package Maker at all, it was literally all pulled from the FS... that was true even in 10.4 (last time I personally used Package Maker for a home server setup and where most of my experience comes from). I had to look up the new docs to see what had changed.

 

If an app's contents or its parent folder is writable by everyone, then anyone at all (even a Guest user) can replace all or part of that app with any files of their choosing. If that seems like a security problem, it is. If it doesn't seem like a security problem, it still is.

If any folder leading to an app is writable by everyone, then anyone at all can alter the folder-path that leads to an app, and make it lead to anything of their choosing. Still a security problem.

 

r-xr-xr-x (0555) would work, but only on folders. That's right: no write permission at all.

If it's not clear why that will still allow write access for root, then review what it means to be root (no permission is denied).

 

The standard practice for the Applications folder is this:

ownership - root:admin
permissions - rwxrwxr-x

This means administrators can still administrate the folder without jumping through hoops, but guests and standard users need to authenticate.

Putting it in there read-only is a great way to annoy users.

 

Any admin serious about actual administration only has to authenticate. It's not a big obstacle. Try it. Even Finder can do an authentication dialog.

On the other hand, since most machines are setup with an admin user as the default user (i.e. the owner, and thus the first acct created), setting no-admin-write is a good way to prevent accidental silent destruction like removing entire folders or apps.

It sorta depends on the target audience, but I've really never had anyone complain about the need to authenticate before removing (or updating) an app. In fact, I've experienced the opposite: some people want an "Are you sure"-type confirmation, one that doesn't interpret the reflexive response as an affirmative answer. For that, few things are better than the authentication dialog (assuming the admin acct has password). When I setup machines for others, I always set them up with a non-admin everyday-user account, and reserve the admin acct only for admin.