1 Aug
2019
1 Aug
'19
1:34 a.m.
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(a)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