[TUHS] Who's behind the UNIX filesystem permission

[Arthur Krewat]

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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190801/3a88ae79/attachment.html>