PAGs, ACLs, privs, MAC...

Albert D. Cahalan (
Thu, 26 Feb 1998 00:55:02 -0500 (EST)

Jim Dennis writes:
> Peter Braam writes:

[quoting fixed, please use standard '>' quoting]

>> Coda as well as other system services want to implement a stricter
>> form of protection and authentication. Unix authorizes processes
>> based on their uid -- the uid defines a partition of the set of
>> processes. Coda finds this partition into protection groups based
>> on uid too coarse; the sets of processes it wants to authorize
>> should be smaller.

Dynamic supplementary groups handle that. You just need to define
the range in use to avoid setgid troubles. (spawn a shell like su)

> Ultimately I suspect that a capabilities model would be
> far easier to implement than ACL's or the proposed "privs"
> (Orange book) features.

Actually, we have code for both. I've lost the URL for ACLs,
but here are privs:

I would like the superset of ACL features provided by Coda and POSIX.
Does that sound good? OK, you can find that on NTFS... I know some
people here really hate M$, but we can still rip off a good idea.
The NTFS and SMB compatibility would be nice.

In case someone doesn't believe that, the GUI is all a lie.
Under the hood, they have 16 general permission bits and 16
object-type-specific permission bits. That is per-ID, not total.
You can add and subtract permission. You can audit some bits
for success and other bits for failure. ACL inheritance is
totally controlable (no, once, yes) per-entry. You can inherit
to files, directories, or both. The ACLs affect a directory
only if you want them to. So you can do "I want FOO on all the
new immediate subdirectories, but not on files, existing
subdirectories, or deeper subdirectories.". The "take ownership"
ability appears to be a general chown() permission.

What would people think of this: ext2 directories start to behave
like BSD 4.4 directories. The 16-bit filename length becomes an
8-bit length and an 8-bit type code. The high 4 bits of i_mode get
stored there, to allow a faster /bin/ls. It also lets the kernel
refuse chdir() to a file without fetching the inode. That leaves
4 spare bits though. I see a use for 2 of them. We could add hidden
flags, one that applies to processes that use "group" permissions and
one that applies to to processes that use "everyone" permissions.
Of course, stat() should lie about the files (Unix98 allows that!),
at least if there is no other permission. The remaining 2 bits
could flag MAC features in the future.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to