Storage of ACLs in file systems: platform overview (draft v1)

[Andreas Gruenbacher]

Robert Watson wrote:
> 
> Linux: ACL Blocks
>         An additional pointer appears in all file system object inodes,
>         which may point to single file blocks containing ACLs.  This
>         makes each ACL use one fs block, but redundancy is detected to
>         improve efficiency, and a block isn't allocated for no ACL
>         being used.
> 
>         Because this is sort of a hackish approach, it does not appear
>         to be scalable to other security-relevant labels (such as MAC
>         labels).  In theory you could add a type to the top of the
>         block, but then you can't have more than one :-).  You could
>         also add type/block data within the raw block, but then the
>         space limitation is a problem.
> 
>         Consistency between inodes and their ACLs are not guaranteed.

True...
The scheme used for on-disk storage of ACLs should be improved to allow for
other attributes as well. I don't know enough about of the requirements of all
the other pieces of information that might some day end up collocated with ACLs.

Mixing shared attributes (ACLs) and un-sharable attributes is not possible
within the same disk block... There are many problems that don't help at all
getting some code running to make experiences with...

For now, I have a version field in each ACL block, so that future versions with
a better block layout (possibly including MAC, ...) can be introduced without
breaking existing file systems. For me that seems good enough to get a decent
ACL system working.
As for extensibility, IMHO you never get it right the first time anyway, so
whichever solution you choose, you have to be careful to keep a path open for
evolution.

The consistency argument is true for the whole ext2 filesystem, since it is non
journaling.

Note that there is another approach (from Rémy Card): He allocates two special
inodes. They are used just like regular files. ACL blocks are allocated within
these files, with sub block allocation. There are some old slides available
about this approach at
<ftp://tsx-11.mit.edu/pub/linux/packages/ext2fs/slides/berlin96/>. (Sorry I
forgot to mention that).

> For example, the disappearence of a MAC label
> from an object might be bad--so might the removal of an ACL on a file (or
> the use of an incorrect ACL).  Correct handling is a hard service to
> provide, and presumably is best done through underlying FS support, as in
> the case of IRIX.

I have been discussing ACLs with a couple of people for some time now. There was
an argument that ACLs are almost always used to grant additional permissions to
a set of users. I'd expect situations where losing an ACL on a file causes
security holes are rare. Also, the design of Posix ACLs seems to support this
argument. From the group file mode bits, one can directly infer what the maximum
possible rights in the ACL are. Other DAC mechanisms may be more critical in
this respect.



I'd also like to hear your opinions about this rather opinion laden posting  :-)


Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, Vienna University of Technology
 a.gruenbacher at infosys.tuwien.ac.at
 Contact information: http://www.infosys.tuwien.ac.at/~agruenba
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message