Re: VFS 64-bit clean

Joshua Buysse (buyssej@coffman.umn.edu)
Fri, 27 Feb 1998 23:10:07 -0600


Actually, *if there are good userspace tools to go with it*, I would
really like the flexibility supplied by this ACL scheme, and would
oppose using the i_dir_acl field for other purposes.

For an example of what I mean by decent userspace tools to edit the
ACLs, take a look at Netware. (I know.) Basically, there's Read,
Write, Erase, Create, Modify, and Filescan (think execute) permissions
for any directory, and a subset of those for a file. All permissions
will inherit down, and you can mask inheritance.

It may seem overly complex on the top, but if it's sufficiently wrapped
by the user tools, it won't be.

Unix permissions have always seemed far too inflexible to me, not
counting execute rights (which are not available in Netware).

-----Original Message-----
From: Theodore Y. Ts'o <tytso@MIT.EDU>
To: Albert D. Cahalan <acahalan@cs.uml.edu>
Cc: linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>
Date: Friday, February 27, 1998 3:05 AM
Subject: Re: VFS 64-bit clean

> Date: Fri, 27 Feb 1998 01:19:08 -0500 (EST)
> From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
>
> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu