[ACL-Devel] Re: OT: ACLs for Linux

[Linda Walsh]

I'm sorta new to the list but wanted to chime in before this goes to the kernel
list and throw out a proposal...

As I understand it, a field is being used in the existing ext2 inode to point to
a block on disk.  The size of the ACL is limited based on the file-system block
size.

I'd like to propose a change -- that the field in the inode be used for an
'attribute' fork (vs. the data fork that holds the normal contents of a file).
As such, it would be a pointer to an disk-block-directory block.  Now there are
a couple of 'reserved' places in the linux implementation of ext2 that are used
by other Operating systems.  Assuming they are still unused, one of the 32 bit
words can be used to store the length of the attr fork (yes, that would limit
attr forks to 4G).  If they were used, that could be worked around by 
 storing the data either in the disk-block-directory (either 1st only or each
depending on implementation desires, space vs.consistancy) or a mandatory first
attr block (assuming the inode had a non-NULL acl-block) entry.  This would
allow for arbitrary extension of ACL's.

In the actual ACL data, the first 4 bytes would define the format / versioning
of the data afterwards then 8 bytes of capabilities followed by 10 reserved bytes.
Then depending on the format encoding, would come either ACL data or 1002 bytes of
MAC/INT data followed by ACL data.

We'd still get to use the regular block allocation mechanism though we might
need attr specific read, write and truncate routines.

The capabilities in the linux kernel are of limited usefulness w/o a capability
based file system.  At the same time, allowing a structure/place for MAC/INT would
be good for future B1 desires.

Secondly, this is a bit of *devil's advocate*: why ACLs?

>From the 'example paper':

Group membership:

andy:users
joe: toolies, big, pricey
lisa:toolies, big
tom:toolies, pricey
mark:toolies, big, pricey

dir structure:

       joe@t4u:/home/toolies > ls -l
       drwx------   2 joe      toolies      1024 Sep 25 12:47 joe 
       drwx------   2 lisa     toolies      1024 Sep 25 12:47 lisa 
       drwx------   2 mark     toolies      1024 Sep 25 13:23 mark 
       drwxr-x---   2 joe      toolies      1024 Sep 25 12:48 shared 
       drwx------   2 tom      toolies      1024 Sep 25 12:48 tom
       joe@t4u:/home/toolies/shared > ls -l
       drwxrwx---   2 joe      big          1024 Sep 25 14:09 big 
       drwxrwx---   2 joe      pricey       1024 Sep 25 14:09 pricey

What is missing?

     1) Lisa doesn't have read access to /home/toolies/shared/pricey. 
     2) Tom doesn't have read access to /home/toolies/shared/big. 
     3) Joe doesn't have write access to files others create in any project subdirectory. 

The first two problems could be solved by granting everyone read access to the
/home/toolies/shared/ directory tree using the others permission bits (making the
directory tree world readable). Since nobody else but Toolies have access to the
/home/toolies directory, this is safe. However, we would need to take great care of
the other permissions of the /home/toolies directory. Adding anything to the toolies
directory tree later on that is world readable is impossible. With ACLs, there is a
better solution. 

The third problem has no clean solution within the thraditional permission system. 
----
	So some comments:  1-Is Lisa, not being on project pricey *supposed* to have
		access to 'pricey'?  Same on 2.  If so, the setgid bit should have
		been turned on in 'shared' and shared is in group 'toolies'.
		If you want to add something world readable in the 'toolies' directory,
		you could set the 'x' bit in toolies(o) and people couln't browse
		but could access specific filenames or subdirectories.
		

	What is the "policy" here -- is no one other than a toolie supposed to have
access to the toolies dir?  Are all directories in 'shared' to be 'toolie' 
read/writeable?  or just readable?  Are all the files in a user's dir private or
public to anyone in toolies?  Under the traditional permission system, if you
want to have a 4 tiered access mode (user,toolie-leader,toolie-member,other),
then you could define groups.  If you had a tool that allowed user creation of
a group -- or if they were pre-created per user: mark-toolie, tom-toolie and lisa-toolie,
then the user's default group was their named group and the toolie-admin belonged to
each user-group, then each user could permit joe access while permitting no other.

	All of these could be created with a group-policy editor, executable by
the 'group-leader-group'.

	One could argue that this is clean relative to the existing security policy.
Having to write system code for special access lists could be argued to be unclean.

	If Joe leaves the toolies group and Mary takes his place as toolies-admin,
this could be changed far more easily if collected in one place (/etc/group) than
by changing ACL's on every file where Joe is present where he should be replaced with
Mary.  Note that this may not be *all* files that have Joe on an ACL.  He could have
been given permission in other directories on other ACLS, some that might be 
deliberately set *just for Joe*.  How do we clean up the mess?  If the group
security policy is spelled out in 1 place, we have a maintanable system, but ACL'S
could result in chaos for group security policies.

	Remember, I'm just playing devil's advocate here.  Are ACL's creatable by
anyone on their own file or only a priviledged user having CAP_CREATE_ACL?

-linda
-------------------------------------------------------------------------
Linux ACL Developers List ---  http://acl.bestbits.at/acl-devel/

To unsubscribe, send a message with `unsubscribe acl-devel'
in the message body to majordomo@bestbits.at.
-------------------------------------------------------------------------