macOS Packagemker issue

[chickeneps]

I have started using PackageMaker and I really like it. I just use the basic stuff, nothing additional. I simply choose the app and other files I want to install, create some custom message for the interface, and I compile.

The one annoying thing is that when the installer is run, it works fine, and installs the app plus other stuff in Applications (I write some folders there), the folders that are written are marked Read-Only for the "admin" and "everyone".

I didn't realize that things written into the Applications were supposed to be like that. None of the other folders at least in my Applications folder are marked Read-only.

How can I turn this off and make these Read-Write for 'admin' and 'everyone'?

 

[Krevnik]

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.

 

[chickeneps]

Thanks for your answer, but no, that doesn't make sense.

In the interface, on a per-item basis in the Configuration tab you can type out the path you want the object to be written to. There isn't a one-to-one relationship between where you get the source during the compilation and where you direct the file to be written to by the user.

For example, here is the Source and Destination paths for the application that I am installing.

Source: /My Projects/My App/Builds/My App.app
Destination: /Applications/My Company Name/My App Name

The problem I have having is that the two folders 'My Company Name' and 'My App Name' are being written with the permissions Read-Only. As you see they have no equivalency to where I am compiling them from. (Even if it did, none of my build folders are Read-Only anyway.)

So, again, my question: how do I direct Packagemaker to write these folders as Read-Write for all users instead of Read-Only?

 

[Krevnik]

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.

 

[chown33]

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.

 

[chickeneps]

Thanks, good points, both of you.

I think the problem really is that the writing of these folders is not controlled by PM but by the users system.

I just had a customer unable to get into these folders. He was running as admin. I'm not sure what he meant, but I just told him that there should be an authorize dialog at the very least when trying to get in; if not, I said as admin he should be able to fix the permissions of these folders. I think in his system the folders weren't just Read-Only but probably something more restrictive.

I think the postflight-script that would re-permission the two folders to Read-Only would be a good idea. Then security would be upheld, I wouldn't have to change around my build setup, and the user wouldn't have these issues. I've never done a postflight script, but I can write in Perl, so it shouldn't be too hard.

Does that sound okay?

What chmod should I do for the folders?

 

[chown33]

What chmod should I do for the folders?

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).

 

[Krevnik]

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.

 

[chown33]

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.