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=-1.0 required=5.0 tests=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 36eda2ca for ; Wed, 31 Jul 2019 19:35:05 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id E775F9BA31; Thu, 1 Aug 2019 05:35:03 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 4C292949CB; Thu, 1 Aug 2019 05:34:50 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 71488949CB; Thu, 1 Aug 2019 05:34:49 +1000 (AEST) Received: from post.cogs.com (post.cogs.com [72.43.6.86]) by minnie.tuhs.org (Postfix) with ESMTPS id 73057948EB for ; Thu, 1 Aug 2019 05:34:47 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by post.cogs.com (Postfix) with ESMTP id 67FDE10249BF21; Wed, 31 Jul 2019 15:34:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at cogs.com Received: from post.cogs.com ([127.0.0.1]) by localhost (post.cogs.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TIYL4BEqw3VC; Wed, 31 Jul 2019 15:34:46 -0400 (EDT) Received: from rrcs-108-176-86-106.nys.biz.rr.com (rrcs-108-176-86-106.nys.biz.rr.com [108.176.86.106]) by post.cogs.com (Postfix) with ESMTPSA id C886C10249BF1B; Wed, 31 Jul 2019 15:34:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) In-Reply-To: Date: Wed, 31 Jul 2019 15:34:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22C0158A-6731-4CA4-BC5A-3CDD3F76F4F9@cogs.com> References: To: Grant Taylor X-Mailer: Apple Mail (2.3564) Subject: Re: [TUHS] Who's behind the UNIX filesystem permission implementation 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: , From: Ben Greenfield via TUHS Reply-To: Ben Greenfield Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" In the Sun System Administration class you got to bring a system up from = nothing which included mucking with inodes. I believe I was taught that = Sun implemented ACLS by assigning to inodes to a file. The first inode = was assigned the unix permissions and the second inode was assigned the = acls permissions and there was some backend mechanism that kept both = inodes referring to a single file. It was a week long class and I found it the best unix experience. I all = machine and no users:) Ben > On Jul 31, 2019, at 2:46 PM, Grant Taylor via TUHS = wrote: >=20 > On 7/31/19 11:00 AM, Toby Thain wrote: >> It may not address "all aspects" since it has been necessary for some = purposes to extend the permission model substantially over time, such as = ACLs, SELinux, etc. >=20 > I thought that ACLs acted as additional gates / restriction points = beyond what standard Unix file system permissions allowed. Meaning that > ACLs couldn't /add/ permission, but they could /remove/ permission. >=20 > I think SELinux behaves similarly. It blocks (removes) existing = permissions. Beyond that, I think SELinux is filtering (removing) = permissions when comparing what (who) is running combined with what is = being run further combined with what it is being run against. So again, = removing existing permissions. >=20 > The only thing that I'm aware of that actually /adds/ permissions is = the capability subsystem. It can give an unprivileged user the ability = to run a binary that can bind to a port below 1024. >=20 >=20 >=20 > --=20 > Grant. . . . > unix || die >=20