Set Default Permissions on New Files or Folders?

I have never encountered a
new folder that had differing permissions from its
parent folder, and have never heard of such a problem
by anyone.

Can you provide documentation of your claim?

localhost:~ kiraly$ mkdir abc
localhost:~ kiraly$ chmod 777 abc
localhost:~ kiraly$ cd abc
localhost:~/abc kiraly$ mkdir def
localhost:~/abc kiraly$ ls -la
total 0
drwxrwxrwx 3 kiraly staff 102 Nov 1 00:35 .
drwxr-xr-x 44 kiraly staff 1496 Nov 1 00:35 ..
drwxr-xr-x 2 kiraly staff 68 Nov 1 00:35 def

As you can see, the newly created folder (permissions 755) does not inherit the permissions of its parent (777). This is how it has always worked in OS X.

Can you provide documentation of your claim?

eMac Mac OS X (10.4.7)

The execute bit is not inherited. Nor is the read or write bit inherited. In fact, no permissions settings at all are inherited. Whenever a new file or folder is created, OS X assigns a default set of permissions no matter what might be the permissions of the enclosing folder.

From this Apple knowledge base article:

Default settings for new files and folders
Ownership settings
User is the user that creates the new file or folder.
Group is default group of the user who created the file or folder.
Permissions
Folders or directories: drwxr-xr-x
Files: -rw-r--r--

By default OSX sets new folders to inherit
permissions from the parent folder. is this not
working for you?

That is absolutely not the default, and has never been the default, on any version of OS X since 10.0.

Among scripters, the rule of thumb is that new items inherit from their parent. I have never encountered a new folder that had differing permissions from its parent folder, and have never heard of such a problem by anyone.

Can you provide documentation of your claim?

I agree with you about the default permissions, but I think that quotation is incorrect about the default group - the group is inherited from from the parent folder, at least in 10.3 and 10.4.

Generally, permissions of new items on a local volume are determined by the ' umask' of the process creating them, and in the case of the OS X GUI, it is usually '022' (octal). The default can also be changed by adding an ' NSUmask' key with an appropriate value in a user's ".GlobalPreferences.plist" file (or that of the main computer though this isn't recommended). A permissive ' NSUmask' with or without setting up a common group is one way to make exchanging documents between users on the same computer easier. Others include running scripts at regular intervals or triggered by "Folder Actions" to modifiy permissions in set directories, or placing all items to be exchanged on a separate volume (or disk image) with "Ignore Ownership" selected. There really isn't enough information in the original post to comment on what would be the easiest, though I agree ACLs would be good for a "Tiger" system...

I agree with you about the default permissions, but I
think that quotation is incorrect about the default
group - the group is inherited from from the parent
folder, at least in 10.3 and 10.4.

Yes, you are correct. The group privilege is inherited from the parent. The group permissions are not. Generally privileges are defined as "who", and permissions as "what the specified user, group, and others can do"

Generally, permissions of new items on a local volume
are determined by the ' umask' of the process
creating them, and in the case of the OS X GUI, it is
usually '022' (octal). The default can also be
changed by adding an ' NSUmask' key with an
appropriate value in a user's
".GlobalPreferences.plist" file (or that of the main
computer though this isn't recommended).

That is true, but many OS X applications will ignore the changed umask setting and apply the OS X default set of permissions anyway. Finder is one such application.

In my opinion, ACLs offer the greatest flexibility in setting up default permissions for folder hierarchies that are maintenance-free. ACLs are one of Tiger's most underrated features, IMO. It would be nice if there was a GUI front end to setting them up. Maybe that is something we can look forward to in 10.5.

..." many OS X applications will ignore the changed umask setting and apply the OS X default set of permissions anyway. Finder is one such application."...

I agree that some applications will ignore the ' NSUmask', but are you sure about the "Finder"? It used the ' NSUmask' settings in "Panther", and I just double checked in 10.4.8 as well. I should mention that it is possible specifically with "Finder" to set a ' umask' property independently of the ' NSUmask' but by default, in the absence of such a setting, it seems to use the global value set for ' NSUmask'.

TinkerTool has an option to change the NSUmask for the GUI. I set it to allow read and write permissions for all users, and then logged out and back in.

Then I opened TextEdit and created a text file. I did a File -> Save, clicked New Folder, and made a new folder ~/abc. Then I saved the file as ~/abc/abc.rtf.

Then I went to Finder and created a new folder ~/abc/def.

Here are the permissions of the folder ~/abc:

localhost:~/abc kiraly$ ls -la
total 24
drwxrwxrwx 5 kiraly staff 170 Nov 1 10:10 .
drwxr-xr-x 45 kiraly staff 1530 Nov 1 10:09 ..
-rw-rw-rw- 1 kiraly staff 336 Nov 1 10:10 abc.rtf
drwxr-xr-x 2 kiraly staff 68 Nov 1 10:10 def

As you can see, the folder and file created by TextEdit respected the new NSUmask settings. The folder "def" created by Finder didn't.

Or maybe I'm just misunderstanding what TinkerTool is doing when it changes the NSUmask.

Hmm, that's odd. Could TinkerTool simultaneously be setting a global ' NSUmask' with the custom value and a separate Finder ' umask' with the default value to exclude the "Finder" from its effects? It might be interesting to see if anything comes up with these:<pre>defaults read com.apple.finder umask
defaults find umask</pre>The ' defaults find' command is case insensitive so both ' umask' and ' NSUmask' should match...

To get more info on fsaclctl, just type "fsaclctl" by itself in a Terminal window. Leave out the "man". The command doesn't do much other than enable or disable ACLs on various volumes. The real work on setting up ACLs is done with the "chmod" command.

Everything else I know about ACLs I learned from this page, and from reading the man page for chmod (type "man chmod" and hit the spacebar seven times to get to the ACL section).

I'll be the first to admit I know very little about how it works, but I'm very glad that it does!

Thanks for an informative discussion, both of you. What I have gathered is that ownership is inherited, but mode is set by the OS according to ACLs.

I see recently rsync is handling a resource file for every music file, while before then music files had no resource fork. Terminal explains:

"Each file has one ACL, containing an ordered list of entries. Each entry refers to a user or group, and grants or denies a set of permissions."

So now I am wondering if the ACL is a resource fork., or if they were added by iTunes 7.

Thanks for an informative discussion, both of you.
What I have gathered is that ownership is inherited,
but mode is set by the OS according to ACLs.

That's almost correct. The owner of a new file is always the user that created it. The only thing that is inherited from the enclosing folder is the specified group. The mode (the permissions for owner, group, and others) is set by the OS.

But the mode is set by ACLs only if you have enabled ACLs (which are off be dafault and must be enabled with the fsaclctl command) and applied them to some folder hierarchy (with the chmod command.) Otherwise OS X will set the default permissions set, which is read+write for owner and read only for all others.

I see recently rsync is handling a resource file for
every music file, while before then music files had
no resource fork. Terminal explains:

"Each file has one ACL, containing an ordered list of
entries. Each entry refers to a user or group, and
grants or denies a set of permissions."

So now I am wondering if the ACL is a resource fork.,
or if they were added by iTunes 7.

I don't know much about what's going on here but I can assure you that if you have never enabled ACLs on your drive, then what you are seeing here are not ACLs.

See my post in this thread for a solution.