[TUHS] Who's behind the UNIX filesystem permission implementation

[George Michaelson]

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 at 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 at bsdimp.com> wrote:
>
>
>
> On Wed, Jul 31, 2019, 12:09 PM Toby Thain <toby at 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
>>