Disclaimer: What I’m describing in this post is not new. Much on the contrary, it is well known and understood, but I wanted to document this because it can be a little bit confusing if you are used to System V, like Sun’s Solaris.

Depending on whether you are using a BSD-like or System V-like systen, the owner of a file system object (file or directory, for example) might be different.

In System V or similar systems, while creating a new file in a directory, the file is owned, by default, by the user’s primary group — remember that every UNIX user has only one primary group, but can belong to many secondary groups (and this limit is usually vendor-specific, and usually near 32) —. An exception to this rule is when the directory has the SetGID bit set.

For example, on Solaris 10:

Sun Microsystems Inc. SunOS 5.11 snv_74 October 2007
# id -a
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),
5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)
# mkdir -p /tmp/foo
# chgrp nuucp /tmp/foo
# ls -ld /tmp/foo
drwxr-xr-x 2 root nuucp 69 Oct 11 17:10 /tmp/foo
# touch /tmp/foo/bar
# ls -l /tmp/foo/bar
-rw-r--r-- 1 root root 0 Oct 11 17:11 /tmp/foo/bar

Since the primary group for user root is group root, and the directory has the setgid permission bit turned off, the file is owned by group root.

However, for directories that have the setgid permission bit turned on the semantics change: creating files and directories within a directory that has the setgid permission bit enabled causes those files and directories to inherit the group from the directory. That is, those files and directories will be owned by the same group as the directory they are contained in:

# rm -f /tmp/foo/bar
# chmod g+s /tmp/foo
# ls -ld /tmp/foo
drwxr-sr-x 2 root nuucp 105 Oct 11 17:11 /tmp/foo
# touch /tmp/foo/bar
# ls -l /tmp/foo/bar
-rw-r--r-- 1 root nuucp 0 Oct 11 17:11 /tmp/foo/bar

However, this is not what I was seeing on Mac OS X, a BSD-like system based on Darwin.

On my Mac OS X laptop, I’m used to store big files (like ISO images) under /Users/Shared. This stems from the fact that I normally use FileVault to encrypt my own files and Mac OS X performs bad when trying to encrypt huge files at high speed (like when copying an ISO file over a Gigabit network using rsync into a FileVault-protected home directory). But I’m digressing. In a default install, /Users/Shared is owned by wheel. What I saw is that all files that I was dropping in /Users/Shared were owned by group wheel while the primary group for my own user is not.

It turns out that the semantic for the creation of new file system entries (files and directories) in BSD-like systems (OpenBSD, FreeBSD, Darwin, Mac OS X, and so on) is exactly the same as the semantics of System V for directories that have the setgid bit enabled. Well, in fact, to be fair, is the other way around: in System V, enabling the setgid bit in a directory makes the directory use the BSD semantics. This is described in the Filesystems HOWTO from The Linux Documentation Project.

BSD semantics says that an object (file or directory), whle being created, always inherits the owning group from the directory where the object is created (no matter if the setgid bit in the parent directory is set or not). Although this makes a lot of sense, sometimes, I prefer the System V semantics that allow any user to decide whether to use BSD semantics or the old System V semantics via the setgid bit. Also remember that System V semantics dictate that if a directory has the setgid bit turned on, any new subdirectory created below it will also inherit the setgid bit.