The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: George Michaelson <ggm@algebras.org>
To: William Corcoran <wlc@jctaylor.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Who's behind the UNIX filesystem permission implementation
Date: Thu, 1 Aug 2019 08:49:09 +1000	[thread overview]
Message-ID: <CAKr6gn19=thho5OU6+tRZfFWdiBPAHNEA5LdD+X7ZpKBd2GErA@mail.gmail.com> (raw)
In-Reply-To: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com>

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 <wlc@jctaylor.com> 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 <imp@bsdimp.com> wrote:
>
>
>
> On Wed, Jul 31, 2019, 12:09 PM Toby Thain <toby@telegraphics.com.au> 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
>>

  reply	other threads:[~2019-07-31 22:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31  9:59 Stephan Han.
2019-07-31 16:49 ` Rodrigo G. López
2019-07-31 17:29   ` Arthur Krewat
2019-07-31 17:58     ` Clem Cole
2019-07-31 18:03     ` Christopher Browne
2019-07-31 20:16     ` Arthur Krewat
2019-07-31 17:00 ` Toby Thain
2019-07-31 17:18   ` Warner Losh
2019-07-31 22:24     ` William Corcoran
2019-07-31 22:49       ` George Michaelson [this message]
2019-07-31 18:46   ` Grant Taylor via TUHS
2019-07-31 19:01     ` Clem Cole
2019-07-31 19:34     ` Ben Greenfield via TUHS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKr6gn19=thho5OU6+tRZfFWdiBPAHNEA5LdD+X7ZpKBd2GErA@mail.gmail.com' \
    --to=ggm@algebras.org \
    --cc=tuhs@minnie.tuhs.org \
    --cc=wlc@jctaylor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).