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

[Ben Greenfield]

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