@Tom Wijsman: thought the had better chances there with this related question. Still learning how this works out here :)
–
JohannesMApr 3 '12 at 10:22

@JohannesM: No problem, welcome to Super User. Depends on the user, depends on the question. This question is regarding Unix permissions and so is kind of OS-independent, strictly one could say that this has nothing to do with Apple and really strictly one could think this belongs to unix.stackexchange.com. But unless the FAQ explicitly prohibits a certain scope we generally don't migrate unless it would really benefit the question. This was covered in a recent blog post... :)
–
Tom WijsmanApr 3 '12 at 10:27

1 Answer
1

Though your installer may have run as admin (for a number of reasons, including where the AU is located in the file system, etc.), your AU may not have the permissions to perform the method above. On the other hand, you can have your AU operate where it has appropriate permissions.

If you want every user to be able to automatically update it without adminitrator permissions, I propose:

Reasonable permissions seem 774, where you grant every user the ability to automatically update it (read, write, execute) and others can only read it. Because the user and group have the same permissions, it doesn't mather what user is set. This will most likely be the user that installed the files, which is either as user or an administrator account. As for the group, staff would indeed make sense.

So, to summarize:

drwxrwxr-- 1 root staff 1970 Jan 01 00:00 Audio Unit

If there is no executable code, you could use 764:

drw-rw-r-- 1 root staff 1970 Jan 01 00:00 Audio Unit

Based on my security considerations

I don't see what credible sources are needed for, you either grant users the right to automatically update or you don't, there is no in between. Just think thoroughly about both possibilties, and then you get to the point you think is right. I don't really like the above approach so will outline a more secure approach here. For security considerations, you could only let the administrator update the bundle, here is why:

User messes around with stuff in the folder.

Other user uses or executes it and loses valuable time or his/her files.