The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Who's behind the UNIX filesystem permission implementation
@ 2019-07-31  9:59 Stephan Han.
  2019-07-31 16:49 ` Rodrigo G. López
  2019-07-31 17:00 ` Toby Thain
  0 siblings, 2 replies; 13+ messages in thread
From: Stephan Han. @ 2019-07-31  9:59 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

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.
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

[-- Attachment #2: Type: text/html, Size: 680 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31  9:59 [TUHS] Who's behind the UNIX filesystem permission implementation Stephan Han.
@ 2019-07-31 16:49 ` Rodrigo G. López
  2019-07-31 17:29   ` Arthur Krewat
  2019-07-31 17:00 ` Toby Thain
  1 sibling, 1 reply; 13+ messages in thread
From: Rodrigo G. López @ 2019-07-31 16:49 UTC (permalink / raw)
  To: Stephan Han.; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Multics had modes per file (https://multicians.org/fjcc4.html) but i don't
know about the origins. the simpler approach of owner/group/other is a
purely Unix creation and i would bet Ken Thompson is behind it all.

i would love to know more.


-rodri

On Wed, Jul 31, 2019, 12:00 PM Stephan Han. <xenonelive@gmail.com> 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.
> 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
>

[-- Attachment #2: Type: text/html, Size: 1463 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31  9:59 [TUHS] Who's behind the UNIX filesystem permission implementation Stephan Han.
  2019-07-31 16:49 ` Rodrigo G. López
@ 2019-07-31 17:00 ` Toby Thain
  2019-07-31 17:18   ` Warner Losh
  2019-07-31 18:46   ` Grant Taylor via TUHS
  1 sibling, 2 replies; 13+ messages in thread
From: Toby Thain @ 2019-07-31 17:00 UTC (permalink / raw)
  To: Stephan Han., tuhs

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.

--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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31 17:00 ` Toby Thain
@ 2019-07-31 17:18   ` Warner Losh
  2019-07-31 22:24     ` William Corcoran
  2019-07-31 18:46   ` Grant Taylor via TUHS
  1 sibling, 1 reply; 13+ messages in thread
From: Warner Losh @ 2019-07-31 17:18 UTC (permalink / raw)
  To: Toby Thain; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 1765 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31 16:49 ` Rodrigo G. López
@ 2019-07-31 17:29   ` Arthur Krewat
  2019-07-31 17:58     ` Clem Cole
                       ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Arthur Krewat @ 2019-07-31 17:29 UTC (permalink / raw)
  To: tuhs

On 7/31/2019 12:49 PM, Rodrigo G. López wrote:
> Multics had modes per file (https://multicians.org/fjcc4.html) but i 
> don't know about the origins. the simpler approach of 
> owner/group/other is a purely Unix creation and i would bet Ken 
> Thompson is behind it all.

TOPS-10 had a 3 octal digit file protection code:

<xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project, 
Programmer] - So if I was [76,5], another user with [76,10] was in the 
same project. Much like UNIX groups.

Owner Protection Codes
7*, 6* - You can execute, read, or change the protection code of the file.
5* - You have unlimited access to the file, except for renaming it.
4* - You have unlimited access to the file.
3 - You can execute, read, or change the protection code of the file.
2 - You have unlimited access to the file, except for renaming it.
1, 0 - You have unlimited access.
* The File Daemon is called on a protection failure on this file (my 
memory is a little fuzzy on this, but I believe it allowed finer grained 
protections).

Protection Codes for Fields 2 and 3
7 - The user cannot access the file.
6 - The user can only execute the file.
5 - The user can execute or read the file.
4 - The user can execute, read, or append to the file.
3 - The user can execute, read, append to, or update the file.
2 - The user can execute, read, append to, update, and write to the file.
1 - The user can execute, read, append to, update, write to, and rename 
the file.
0 - Unlimited access, including changing the protection code of the file.

The name TOPS-10 was first used in 1970, but the monitor itself dates 
back to 1964. I'm not sure when these protection codes came into being, 
though.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  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
  2 siblings, 0 replies; 13+ messages in thread
From: Clem Cole @ 2019-07-31 17:58 UTC (permalink / raw)
  To: Arthur Krewat; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

FWIW: Before TOPS, there was MIT's CTSS.   The DEC Project, Programmer
Number (a.k.a. PPN) idea seems to have been similar to the People and *Problem
Number* idea of CTSS, which allowed for directories of your own files and
as well as your group (shared problem number). As Rodrigo pointed out
Multics also had a form of ACLs (UNIX used ACL's just very simplified ones).

So I'm not sure where to pin this specific idea.  I think it was a bit like
a lot of CS ideas, different people were playing with different aspects of
different ideas at the time, and brillance of Ken and Dennis was putting
some of the *best ideas *of the day *together* and adding a few of their
own into a simple implementation that was good enough to do real work.

Clem


On Wed, Jul 31, 2019 at 1:29 PM Arthur Krewat <krewat@kilonet.net> wrote:

> On 7/31/2019 12:49 PM, Rodrigo G. López wrote:
> > Multics had modes per file (https://multicians.org/fjcc4.html) but i
> > don't know about the origins. the simpler approach of
> > owner/group/other is a purely Unix creation and i would bet Ken
> > Thompson is behind it all.
>
> TOPS-10 had a 3 octal digit file protection code:
>
> <xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project,
> Programmer] - So if I was [76,5], another user with [76,10] was in the
> same project. Much like UNIX groups.
>
> Owner Protection Codes
> 7*, 6* - You can execute, read, or change the protection code of the file.
> 5* - You have unlimited access to the file, except for renaming it.
> 4* - You have unlimited access to the file.
> 3 - You can execute, read, or change the protection code of the file.
> 2 - You have unlimited access to the file, except for renaming it.
> 1, 0 - You have unlimited access.
> * The File Daemon is called on a protection failure on this file (my
> memory is a little fuzzy on this, but I believe it allowed finer grained
> protections).
>
> Protection Codes for Fields 2 and 3
> 7 - The user cannot access the file.
> 6 - The user can only execute the file.
> 5 - The user can execute or read the file.
> 4 - The user can execute, read, or append to the file.
> 3 - The user can execute, read, append to, or update the file.
> 2 - The user can execute, read, append to, update, and write to the file.
> 1 - The user can execute, read, append to, update, write to, and rename
> the file.
> 0 - Unlimited access, including changing the protection code of the file.
>
> The name TOPS-10 was first used in 1970, but the monitor itself dates
> back to 1964. I'm not sure when these protection codes came into being,
> though.
>

[-- Attachment #2: Type: text/html, Size: 3628 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  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
  2 siblings, 0 replies; 13+ messages in thread
From: Christopher Browne @ 2019-07-31 18:03 UTC (permalink / raw)
  To: Arthur Krewat; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]

On Wed, 31 Jul 2019 at 13:29, Arthur Krewat <krewat@kilonet.net> wrote:

> On 7/31/2019 12:49 PM, Rodrigo G. López wrote:
> > Multics had modes per file (https://multicians.org/fjcc4.html) but i
> > don't know about the origins. the simpler approach of
> > owner/group/other is a purely Unix creation and i would bet Ken
> > Thompson is behind it all.
>
> TOPS-10 had a 3 octal digit file protection code:
>
> <xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project,
> Programmer] - So if I was [76,5], another user with [76,10] was in the
> same project. Much like UNIX groups.
>
> Owner Protection Codes
> 7*, 6* - You can execute, read, or change the protection code of the file.
> 5* - You have unlimited access to the file, except for renaming it.
> 4* - You have unlimited access to the file.
> 3 - You can execute, read, or change the protection code of the file.
> 2 - You have unlimited access to the file, except for renaming it.
> 1, 0 - You have unlimited access.
> * The File Daemon is called on a protection failure on this file (my
> memory is a little fuzzy on this, but I believe it allowed finer grained
> protections).
>
> Protection Codes for Fields 2 and 3
> 7 - The user cannot access the file.
> 6 - The user can only execute the file.
> 5 - The user can execute or read the file.
> 4 - The user can execute, read, or append to the file.
> 3 - The user can execute, read, append to, or update the file.
> 2 - The user can execute, read, append to, update, and write to the file.
> 1 - The user can execute, read, append to, update, write to, and rename
> the file.
> 0 - Unlimited access, including changing the protection code of the file.
>
> The name TOPS-10 was first used in 1970, but the monitor itself dates
> back to 1964. I'm not sure when these protection codes came into being,
> though.
>

Interesting; similar, though not identical to some material I captured back
in the 1990s on TOPS-10 FILDAE in a discussion about Linux filesystem
permission semantics...

It seemed interesting, so I added it to a web page:
linuxfinances.info/info/fs.html

The claim is that there would be a fildae control file like the following:
# anything in a directory named "private" is off limits
*/private/*:*:*:*:
# people in group "foo" get full (create, delete, read, write,
# execute) access to everything in the foo project directory
~/projects/foo/*:*:foo:*:cdrwx
# people playing mygame can update the high score file
~/mygame/score.dat:*:*:
~/mygame/bin/mygame:rw
# some friends have access to the RCS files for mygame
~/mygame/src/RCS/*:dennis,kevin,josh:*:
/usr/bin/ci:rw
~/mygame/src/RCS/*:dennis,kevin,josh:*:
/usr/bin/co:rw
# I'll put stuff I want everyone to read in my ~/public directory
# I'll make the public directory 744, so no one will actually have
# to check .access_list, but I'll still put in this entry for
completeness
~/public/*:*:*:*:r# anything left over gets no access*:*:*:*:
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

[-- Attachment #2: Type: text/html, Size: 3933 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31 17:00 ` Toby Thain
  2019-07-31 17:18   ` Warner Losh
@ 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
  1 sibling, 2 replies; 13+ messages in thread
From: Grant Taylor via TUHS @ 2019-07-31 18:46 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

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.

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.

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.

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.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  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
  1 sibling, 0 replies; 13+ messages in thread
From: Clem Cole @ 2019-07-31 19:01 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Wed, Jul 31, 2019 at 2:46 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> I thought that ACLs acted as additional gates / restriction points
> beyond what standard Unix file system permissions allowed.
>
It's really how strict you want to be in the definition of an ACL.   UNIX
uses the same basic/simple model but traditional UNIX style ACLs of 3
options of 3 modes are implemented are just more coarsely defined than say
VMS or later NT or SELinux, uses for their file systems.   It's arguable
that the extra granularity of the others actually adds a great deal in
actual day to day use cases.

At one time, I will admit that I had thought VMS style ACLs might be more
helpful to UNIX and we added them to one of our file systems, but when I
look back on 40 years of using anything beyond UNIX style ACLs its been
pretty rare when I actually needed much more (*i.e.* theory vs. practice).

The problem is the programming interface tends to get more difficult when
you add some of the extra features.   To me the brilliance to UNIX has
always been getting down to a very simple interface that was "good enough"
to get the *job done* and not so full of *extra stuff *that it gets in the
way (which tends to be a complaint by way with Linux -- which does have a
lot of new/rich features, but so full of some many different features
theses days you have to wonder is/was it worth it).

To me, it's arguable that ACL's beyond R/W/E and U/G/E is really needed in
practice.

Clem

[-- Attachment #2: Type: text/html, Size: 2801 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  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
  1 sibling, 0 replies; 13+ messages in thread
From: Ben Greenfield via TUHS @ 2019-07-31 19:34 UTC (permalink / raw)
  To: Grant Taylor; +Cc: 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 <tuhs@minnie.tuhs.org> wrote:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  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
  2 siblings, 0 replies; 13+ messages in thread
From: Arthur Krewat @ 2019-07-31 20:16 UTC (permalink / raw)
  To: tuhs

Sorry to reply to myself, but I wanted to add one note to this, and 
didn't, which pertains to the "rename" versus "update" part of file 
protections in TOPS-10, and perhaps was a bug that was never fixed, or 
it was, and I didn't know it.

In TOPS-10, you use the monitor call ENTER to update (write to) an 
existing file. It uses a common argument list with LOOKUP and I think a 
few other calls, that include the file name and extension. If a file had 
a 4 protection code for you, you could LOOKUP the file, then ENTER it 
with a different filename, and the filename would change, effectively 
renaming the file which you would think required a 1 protection code. 
You could also, if I recall correctly, specify a different protection.

The significance of this? Many installations put files in SYS: ([1,4]) 
that had a 4 protection code so they could be written to by various 
applications users ran, or it was an oversight by a system 
administrator. Using DDT, one could easily whip up a short piece of code 
to rename any file in SYS: that had a 4 protection code, rename it to a 
.SAV or .SHR (if it needed a highseg) and basically "hide" behind 
another program, such as LOGIN.EXE (When EXE was introduced, I think in 
version 6, TOPS-10 still supported .SAV, .SHR, and .HGH but would 
attempt to run the .EXE first if you didn't specify an extension).

Certain programs in SYS: like LOGIN had JACCT privileges - full rights 
to everything, including device I/O. So, find a writable file in SYS:, 
rename it to LOGIN.SAV, copy PIP over it, or something you cobbled up 
yourself, and take over the system without causing any other issues 
except that missing writable file.

JACCT priv was much like "setuid" in UNIX - except it was a hardcoded 
list of filenames in the monitor (I think mostly or exclusively in SYS:) 
that would get carte blanche access to everything. I believe by version 
7, some programs had been deprecated out of SYS, but they still existed 
in the JACCT list in the monitor.

And boy, there were a lot of systems out there on Telenet or the ARPANET 
that had files in SYS: protected with a 4. Side note: Telenet was BBN's 
attempt to create a private sector ARPANET. 
https://en.wikipedia.org/wiki/Telenet - A late night dumpster dive at 
Radio Shack in the very early 80's got me a local dialin number.

Sorry for the lengthy dissertation :)

On 7/31/2019 1:29 PM, Arthur Krewat wrote:
> TOPS-10 had a 3 octal digit file protection code:
>
> <xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project, 
> Programmer] - So if I was [76,5], another user with [76,10] was in the 
> same project. Much like UNIX groups.
>
> Owner Protection Codes
> 7*, 6* - You can execute, read, or change the protection code of the 
> file.
> 5* - You have unlimited access to the file, except for renaming it.
> 4* - You have unlimited access to the file.
> 3 - You can execute, read, or change the protection code of the file.
> 2 - You have unlimited access to the file, except for renaming it.
> 1, 0 - You have unlimited access.
> * The File Daemon is called on a protection failure on this file (my 
> memory is a little fuzzy on this, but I believe it allowed finer 
> grained protections).
>
> Protection Codes for Fields 2 and 3
> 7 - The user cannot access the file.
> 6 - The user can only execute the file.
> 5 - The user can execute or read the file.
> 4 - The user can execute, read, or append to the file.
> 3 - The user can execute, read, append to, or update the file.
> 2 - The user can execute, read, append to, update, and write to the file.
> 1 - The user can execute, read, append to, update, write to, and 
> rename the file.
> 0 - Unlimited access, including changing the protection code of the file.
>
> The name TOPS-10 was first used in 1970, but the monitor itself dates 
> back to 1964. I'm not sure when these protection codes came into 
> being, though.
>


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31 17:18   ` Warner Losh
@ 2019-07-31 22:24     ` William Corcoran
  2019-07-31 22:49       ` George Michaelson
  0 siblings, 1 reply; 13+ messages in thread
From: William Corcoran @ 2019-07-31 22:24 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

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<mailto:imp@bsdimp.com>> wrote:



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


[-- Attachment #2: Type: text/html, Size: 2805 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Who's behind the UNIX filesystem permission implementation
  2019-07-31 22:24     ` William Corcoran
@ 2019-07-31 22:49       ` George Michaelson
  0 siblings, 0 replies; 13+ messages in thread
From: George Michaelson @ 2019-07-31 22:49 UTC (permalink / raw)
  To: William Corcoran; +Cc: TUHS main list

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
>>

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-07-31 22:49 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-31  9:59 [TUHS] Who's behind the UNIX filesystem permission implementation 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
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

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).