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.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,LOTS_OF_MONEY,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 8c7fb973 for ; Wed, 31 Jul 2019 22:49:57 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5EFCF9BA07; Thu, 1 Aug 2019 08:49:56 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A537F949CB; Thu, 1 Aug 2019 08:49:27 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=algebras-org.20150623.gappssmtp.com header.i=@algebras-org.20150623.gappssmtp.com header.b="ofqBe/zw"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 8E236949CB; Thu, 1 Aug 2019 08:49:25 +1000 (AEST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by minnie.tuhs.org (Postfix) with ESMTPS id A2EBA948EB for ; Thu, 1 Aug 2019 08:49:21 +1000 (AEST) Received: by mail-io1-f51.google.com with SMTP id f4so140025046ioh.6 for ; Wed, 31 Jul 2019 15:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jnFZ+gE2A7kuWSSynLEYSYC0s/VajINnfKHDhfCU6Z8=; b=ofqBe/zwOTlEQNSmTxHmgDyqRj59CgKJOsOxp80jXqBBEnN4z1YuEQXXYL961JArk8 m/W/Y3wb6DSbOFi+g8ULrTy2efkRKhwQiMJfrzE7O288DwJyj+2K/ZDiA/r/tdh09qmx VGlsfMYOZ6JmR4hknFjHUdmB7XVdY1A4b/xdnzfX3YMeWwsUZwiYWpt60RAbHxn0qTQi dDEZqOSpBhmve+1dA80vf6AGvbGdhAaX1IE7Z2yPtTZJPi7orkv2NbpVFd50yiSs6FW+ hKTp1MundH2z+YLM5sxScLovfp8J7yl5En6HZ0qyTT5zAH77XqLOQp2KLXPhNCuO/a4T xAcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jnFZ+gE2A7kuWSSynLEYSYC0s/VajINnfKHDhfCU6Z8=; b=Dltd6g3QG3HFvGRLequ0vKWF3v+yWn9PzOkjypNBQMFun8MNvXwu+9uYxPU0mhtE/A Zj0i+WEyP9zSL1po1APXUcCAriQNj4d5gb+HfmRPLg5oct/ypsCN3SBrRAacSzPCfAGg 1QLWnFAlDddPpZD/F0Zag6c9WYoYZNFad1VGuzDgBqboySmQhqZaYE7/hMvjeFW0CtUZ oGzxzGwXYxB1hgH5prsWJwNy/ncMc+c2DUSW9hY4T0lvnq95SkozafuPCtUYKOKeqLrG qKtTVHlRBkl/LfwiUoCACco0247yP29S+MKKj9VKH+d0lgfUI4+TrKC2pmCT0VWKCsAJ m5wA== X-Gm-Message-State: APjAAAVfnv/DpH/T7LGRPAfB/sGPYgVcn0eColnqLgoSVRQfAKmGIzeu LWHQBuQF8Jm2B6OrwOc5qlqrljzkNFf4y9+mn1hXjhT/ X-Google-Smtp-Source: APXvYqxhkW4+spr098hg3eJkSh7BxCLMXMocwZGsNw8f4AHS3DLjkTCbXgC9HT+AqbgU5Qukgd/02P9g6mgXDJB2dNM= X-Received: by 2002:a5d:9550:: with SMTP id a16mr76638619ios.106.1564613360881; Wed, 31 Jul 2019 15:49:20 -0700 (PDT) MIME-Version: 1.0 References: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com> In-Reply-To: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com> From: George Michaelson Date: Thu, 1 Aug 2019 08:49:09 +1000 Message-ID: To: William Corcoran Content-Type: text/plain; charset="UTF-8" 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: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" The "useful layer of indirection" story carries the seeds of its own problem, if you consider xattr on files. They always prove harder to deal with, lie in cat -v extended options, cannot be invoked without bigger wetware cache memory than I hold, which requires a retreat to the man page, and crop up at the worst possible times, such as when you are doing buildworld installworld sequences, they blow up, and you have xattr locked files with setuid bit littering the FS tree. chmod can't do them with octal bit settings or they lie in octal spaces I don't understand further up from 777 Necessary but evil. What I like about user/group/other is that the group memberships list is independent, but maps into the tested space in the flags for chmod. If I want to grant somebody permission in group sense, I make sure we share a group and I arrange for the group to be set. If I cannot make the dir be group the same, I use --x permissions on other to give them transitive rights down into the file. It would be possible to argue creat(e) was a distinct permission from write. I think I heard Dennis say he regretted some aspects of the model around "is write the same as create" at an AUUG once, (I mean more than just his joke about calling it creat() not create() -he actually said there were arguments both sides to breaking out more modes of behaviour on things, and modifying the contents of a created named entity is not the same as naming it) And Microslop and xattr and I think VMS do indeed go to the "I can make things as well as change things" place. So yes, write permissions on the directory are the "proper" place to say "you can make things" but then you're in an indirection: the dir block is not the file, the file name is in the dir block, oh dear, so maybe we mean we want Apples resource fork and the data fork, a model I could never understand? No please.. but.. then again.. Oh dear. Its just a projection into a UNIX FS to make this a file and a .attr file, thats not how Apple "Ideated" it, but still. All designs come with costs. I guess if you like apple pie, you can dream about peaches, but peaches aren't apples. On Thu, Aug 1, 2019 at 8:36 AM William Corcoran wrote: > > No filesystem permission discussion would be complete without mentioning United States Patent US 4135240. > > Set user ID! > setuid > setgid > > (Hmmmm, I believe there is an Et al. missing after the inventors name, Dennis Ritchie, on the face of this patent, right?) > > Bill Corcoran > > > > On Jul 31, 2019, at 1:18 PM, Warner Losh wrote: > > > > On Wed, Jul 31, 2019, 12:09 PM Toby Thain wrote: >> >> On 2019-07-31 5:59 a.m., Stephan Han. wrote: >> > Hello Unix enthusiasts. >> > >> > I'd like to know who or the group of people behind implementing this >> > filesystem permission system. >> > Since we are using this system for nearly 40 years and it addresses all >> > the aspects of the permission matter without any hustle. >> >> 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. > > > He did say they solved the problem without hassle. All those other things introduced hassle. :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits... > > Warner > >> --Toby >> >> >> > I'm inspired to know who/how came up with this theory? >> > Also if it derived from somewhere else or If there's an origin story >> > about this, it would be worth to share. >> > >> > Cheers. >> > Stephan >> > >> > -- >> > No When >>