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

[Andreas Gruenbacher]

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

Thanks for joining the discussion.

> 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.

That's true in the acl code. The new (unstable) version allows filesystems to
implement arbitrary mechanisms for storing meta data. In the latest interface I
proposed access to this meta-information (which seem to be about the same as the
attributes you have in mind) is accessed via symbolic constants (numbers) rather
than names. Strings might be a better idea.

This of course does not solve the problem of storing the data on the filesystem.

> 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.

This is an important design decision. It seems there are two philosophies here.
One is to store arbitrary metadata for files (Irix filesystem). ACLs and other
metadata are then allocated per file. The other approach is to allocate space
for ACLs like I'm currently doing. From my understanding this is similar to
Solaris ACLs.

There's one free entry in ext2 inodes (i_file_acl). I guess we will have one of
the above solutions, but not both.

The arbitrary meta-data approach leaves us more choices in the future. On the
other hand, it's more expensive (disk space, runtime overhead). The raw-block
solution is fast, but not as easy to extend. If the issue is to store more data
than fits on one disk block, the first block could be used to store indexes to
additional blocks.

Another issue is sharing meta-data among inodes. In the current stable version,
ACL blocks have a reference cound and are shared among inodes. This saves both
memory and time. I often find myself issuing commands like `chmod -R ...'. These
are relatively cheap with shared blocks, and muck less so with the meta-data per
inode approach.

My current position is that raw blocks are good enough. A single 1K disk block
can easily hold ACL, default ACL, Capabilities, MAC and IL labels and still
leave room for extension. See the file <include/linux/ext2meta.h> in the
linux-*-acc patch, where that structure is defined. I'd still like to hear
others' opinions on this topic.

Another good thing would be an implementation of arbitrary meta-data on ext2 to
play with, of course  :-)

> 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.

True enough.

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

I know the example isn't very good. It's hard to find a simple example that
can't be implemented with user-group-others. [Un]fortunately, the
user-group-others permission scheme can be stretched very far. The results are
not beautiful and hard to maintain, but they often work.

Please give me some time to respond to the rest of your sugestions.

Just a few quick remarks:

> 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.

You'd use group ACL entries if that level of of flexibility is desired.

>         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?

The owner or a user capable of CAP_FOWNER can modify ACLs. This is one of the
charms of ACLs. Users can choose which other groups/users they permit access to
their files without the sysadmin's help.


Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher@computer.org
 Contact information: http://www.bestbits.at/~ag/
-------------------------------------------------------------------------
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.
-------------------------------------------------------------------------