From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 7115c89c for ; Thu, 1 Aug 2019 16:36:05 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5399F9B838; Fri, 2 Aug 2019 02:36:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 33601949CB; Fri, 2 Aug 2019 02:35:43 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=kilonet.net header.i=@kilonet.net header.b="fGFramMV"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C5EE1949CB; Fri, 2 Aug 2019 02:35:40 +1000 (AEST) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) by minnie.tuhs.org (Postfix) with ESMTPS id 53B8B94903 for ; Fri, 2 Aug 2019 02:35:40 +1000 (AEST) Received: from medusa.kilonet.net ([72.69.11.12]) by :SMTPAUTH: with ESMTPA id tE3FhrDlwBnlItE3GhcDmi; Thu, 01 Aug 2019 09:35:39 -0700 Received: from [199.89.231.101] (ender.kilonet.net [199.89.231.101]) by medusa.kilonet.net (8.14.8/8.15.1) with ESMTP id x71GZbiN009915 for ; Thu, 1 Aug 2019 12:35:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kilonet.net; s=default; t=1564677337; bh=VXHBowHLov+SUSpHWIdy2Dj9HD0E7DkNRefvbP+loes=; h=Subject:To:References:From:Date:In-Reply-To; b=fGFramMVOkpuMv667cO2W4hA1+fgLWEbmu8KoK6w7gpQTBy1odNKducQLGefmeafa xXtKZ7LhXLvRPTNF6MV2cQP/NxaNxKYRFZJGltNWSt3tr0jWiqzAcdXMU5BsLeZyP/ 9Y5uo52NPXR+sujhAkYEjavcnrcnf8TaYq1bAGuE= To: tuhs@minnie.tuhs.org References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> From: Arthur Krewat Message-ID: <6bdbf145-7bd3-971b-0ced-3ad1cae8b33d@kilonet.net> Date: Thu, 1 Aug 2019 12:35:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3174FE5E9BBB07032DE1361A" Content-Language: en-US X-CMAE-Envelope: MS4wfC8hkhCLMsMgOyuBiUa78h8S9RFIAvoKDbC2Ya6kFVN4QUYb+saW7/3ltlFxcmXfmLHvIBvoMgj/m+uh0B09MDV7sVKyhFCXq4/f0nwbnzFVwoA4BNOx /DagGGm5W/AXVOFmOrDKLhGFgFsuP9vHe2onK71JPzRzddlFM5j3Yfot Subject: Re: [TUHS] Who's behind the UNIX filesystem permission X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------3174FE5E9BBB07032DE1361A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. > --------------3174FE5E9BBB07032DE1361A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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.


--------------3174FE5E9BBB07032DE1361A--