Types of ACL:
ACCESS_ALLOWED AUDIT_SUCCESS ALARM_SUCCESS [privs too]
ACCESS_DENIED AUDIT_FAIL ALARM_FAIL
Inheritance control:
CONTAINER_INHERIT inherited by directories
OBJECT_INHERIT inherited by files, pipes, devices...
INHERIT_ONLY does not affect this inode
NO_PROPAGATE_INHERIT don't propagate CONTAINER_INHERIT and OBJECT_INHERIT
DEFAULT_DIR CONTAINER_INHERIT | INHERIT_ONLY | ???
DEFAULT_ACCESS OBJECT_INHERIT | INHERIT_ONLY | ???
PROPAGATE_INHERIT_ONLY needed to resolve Digital Unix vs. NT issues?
NO_PROPAGATE_INHERIT_ONLY maybe this instead, depending on default above
That seems to cover POSIX, Coda/AFS/DFS, Digital, NTFS/SMB...
I might get a chance to code it for credit next fall. The hard
part may be expanding the kernel to understand new permission
bits, since there would be 32 for each ID.
I'm not convinced this kind of complexity is either needed or would be
useful. The hardest part of any security system is to get people to use
it, and there are many people who argue that even Unix permissions bits
are too hard for users to get right. Certainly, the field is litterred
with the wreckage of Unix systems broken into by hackers because the
System Administrator misconfigred some of the directory or file
permissions on their system.
ACL's provide a lot of new functionality, at the cost of a somewhat more
complicated interface, and it's probably worth it (although there are
some who would argue that point). Having 36 different kinds of types
ACL's that can belong to an inode, however, goes far over the line of
what is actually going to be useful to nearly all system administrator,
and fails the cost/benefit analysis, IMHO.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu