1 Aug
2019
1 Aug
'19
6:35 p.m.
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.