* [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 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: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 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 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
* 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
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).