There's also the setgid bit on directories, that when files are created, they will be in the group that the parent directory has on it. Also, I don't think it's been mentioned, but there's the setuid bit on directories - otherwise known as the sticky bit. When set, even if you have rights to "write" the directory (meaning, delete files), you can't delete those owned by other users. Useful for /tmp I have no idea what the timeline is for either of these features :) On 8/1/2019 12:22 PM, John P. Linderman wrote: > > *Yet clean as the idea of groups was, it has been used only > sporadically (in my experience).* > > > As I recall it, the original "basic groups" were essentially "us" and > "them". "Us" was everyone in the "in crowd", "them" was everyone else. > Since the basic groups were rather extensive, it was prudent to turn > group write permission off in your default umask. But that made groups > rather clunky. You were in only one group at a time, so you had to > "chgrp" to a select group, and then remember to set your umask to > allow group write permission so others in the group could modify > files. This changed when you could be in multiple groups at the same > time (a BSD invention?), and your primary group automatically changed > to the group owning your current working directory (iff you belonged > to that group). This made it unnecessary to do an explicit chgrp in > most cases. Having group write permission off in your default umask > was now a nuisance. We fixed that by giving everyone an unshared > primary group id, typically the same as the uid. It then became safe > to make group write permission on by default. This made groups much > more useful. Anyone in a group (but only those members) could create a > directory owned by that group, and group members working in that > directory defaulted to creating files (and subdirectories) group-owned > by and writable by all the members of the group. It just worked. >