Re: VFS 64-bit clean
Albert D. Cahalan (acahalan@cs.uml.edu)
Sat, 28 Feb 1998 00:33:01 -0500 (EST)
>> 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.
There is good reason for this. Some system admins will spend most of
their time on Coda filesystems. They will want to use the same tools
and get the same behavior on local ext2 filesystems. Some system admins
will use Digital Unix for "important" tasks (job on the line) and Linux
for other tasks. They will want Linux ACLs to behave exactly like the
ACLs on Digital Unix. Some system admins must serve filesystems to
Windows NT. They will want the GUI on client machines to work in the
expected manner, perhaps avoiding major security holes created by the
incompatible unix permission system.
I wouldn't expect normal admins to deal with so many types of ACLs
directly. (actually, types of inheritance for only a few ACL types)
If the admin decides to use the Coda tools, permissions would be
converted in a conservative way. The complexity is needed so that
user tools can provide simple familiar interfaces (Coda, Digital, NT)
that work the way an admin might expect them to work.
I'm thinking that an efficient implementation would use 3 inode
pointers on directories: the directory itself, new files, and new
subdirectories. Only subdirectory creation could require writing
a new ACL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu