Date: Sun, 07 May 2000 01:17:40 +0200
From: Andreas Gruenbacher <a.gruenbacher@bestbits.at>
To: Linux ACL Developers List <acl-devel@bestbits.at>
Subject: [ACL-Devel] Re: Extended attributes implementation -- some docs

This is a multi-part message in MIME format.
--------------899A113C071253D325A3B707
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This should become some sort of design document  :-)

Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher@computer.org
 Contact information: http://www.bestbits.at/~ag/
--------------899A113C071253D325A3B707
Content-Type: text/plain; charset=us-ascii;
 name="ext_attr.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ext_attr.txt"

EXTENDED FILESYSTEM ATTRIBUTES

Andreas Gruenbacher <a.gruenbacher@computer.org>
7 May 2000


TABLE OF CONTENTS
-----------------

OVERVIEW
WHY DO WE NEED THIS?
BACKGROUND
EXTENDED ATTRIBUTES
ISSUES
VFS IMPLEMENTATION DESIGN
FILESYSTEM IMPLEMENTATION CHOICES
EXT2 EXTENDED ATTRIBUTES
...
REFERENCES


OVERVIEW
--------
...


WHY DO WE NEED THIS?
--------------------

Linux  is  currently  behind  other  commercial  and  free  flavors of
UNIX-like operating systems as far as  advanced security  concepts are
concerned. For high security ratings several mechanisms  are mandated.
These mechanisms require security objects to be associated with files.
Since  Linux  does  not  currently  include  support for  storing such
objects, these advanced security mechanisms did not develop  very well
so  far.  By  including  extended  attributes  in  the  kernel,  these
mechanisms will become  stable faster,  which will  allow Linux  to be
used in areas in which it currently is inappropriate.

Capabilities  are already  part of  the kernel,  but suffers  from not
being able to associate capabilities with executables (there  are even
several  hacks  available  to  work  around  this limitation,  such as
elfcap). There  is also  a mostly  complete Posix  ACL implementation,
etc.


BACKGROUND
----------

There are two common approaches for associating additional information
with files/directories.  The one  implemented by  SGI Irix  and Compaq
(Digital)   Tru64   is   similar   to   the  design   described  here.
Limited-length  attributes  are  associated  with  inodes.

The  other  approach  is   to  associate   arbitrary-length  resources
("forks") with inodes. This approach  is used  by the  Apple Macintosh
HFS filesystem [and which others?].

Fixed-length attributes are accessed  as atomic  objects. They  can be
implemented  fast,  with  little  overhead.  For extending  the kernel
security functionality, this approach seems most appropriate.

Forks are accessed like regular files. In other words, these resources
are  similar  to  a  directory  behind  a  regular file.  While kernel
security  extensions could  be implemented  atop forks,  this involves
additional overheads. The  real users  of forks  would probably  be in
userspace.

Forks are an additional level of abstraction that can be be achived in
userspace  with  a  modified  design.  Implementing them  would simply
extend the filesystem namespace. HFS forks also are mapped  to regular
files in Linux, rather than inventing a new interface.

Extended attributes, on the other hand, seem very much what  is needed
to  store  the  additional  system objects  required for  the projects
mentioned.  The  same mechanism,  once implemented,  can also  be made
available for storing small amounts of user space information.


EXTENDED ATTRIBUTES
-------------------

Extended attributes are name/value  pairs associated  permanently with
files and directories, similar to  the environment  strings associated
with a process. That is, an attribute may be defined or  undefined. If
an attribute is defined, its value  may be  empty or  non-empty. Names
are zero-terminated strings. Values are arbitrary binary data.

Attributes are small chunks of information accessed as atomic objects.
Reading retrieves the whole value of an attribute and  stores it  in a
buffer. Writing  replaces the  previous value,  if that  attribute was
previously defined. If it was not, the new attribute is added.

User and system attributes are supported. System attribute names begin
with a '$' character (e.g., "$acl").  Attributes names  beginning with
an alphabetic character denote user attributes (e.g., "charset").

Processes that have search access to a directory  also have  access to
the list of attribute names of files in that directory. Access  to the
values of user attributes is subject to the same permissions as access
to the file's contents. Access to system  attribute values  depends on
the  name  of  the  attribute. Both  reading/writing and  the accepted
values may be restricted.

System attributes will be used to store  system security  objects such
as  Access  Control  Lists,  Mandatory   Access  Control   labels  and
Capabilities. Other uses are not precluded. User  objects may  be used
to store small amounts of additional information such as the character
sets of files, checksums, etc. Storing bigger items such as thumbnails
is  currently  not  possible.  However,  this  is  a  possible  future
extension.


ISSUES
------

Extended attributes are intended to be used for system objects such as
Access Control Lists, Mandatory  Access Control  labels, Capabilities,
possibly some sort of auditing information, etc.

These attributes need  to be  retrieved fast.  Objects such  as Access
Control  Lists  (ACLs)  and  Mandatory  Access  Control  (MAC)  labels
participate in access control decisions.

Writing  extended  attributes  is not  extremely time  critical, since
updates to security settings are much  less frequent.  (The read/write
ratio may be comparable, but  probably is  higher than  the read/write
ratio of regular files).

Values  are  typically  small.  The size  is in  the order  of several
hundred bytes or less. This allows attributes to be simply copied in
one piece.

Extended attributes can be  associated with  files and  directories. A
consequent  extension  is  to  also  allow  extended attributes  to be
associated with  processes. This  simplifies handling  of Capabilities
and per-process ACLs, for example (both types of  objects may  also be
associated with processes---for ACLs, that's similar to the umask).


VFS IMPLEMENTATION DESIGN
-------------------------

The  system  call  and  VFS  layer  consists  of  three  system  calls
ext_attr_path,  ext_attr_fd,   and  ext_attr_proc,   for  manipulating
extended attributes of a files (pathname and open file) and processes.
These  system  calls  are  used  to  manipulate  both user  and system
attributes.  Semantic  restrictions  are  checked  in  the   VFS.  Two
downcalls to the physical filesystem (for  setting and  retrieving) do
the actual filesystem work.

For user attributes, access control is performed in the VFS.

For  system  attributes,  a separate  handler is  used for  each named
system attribute defined that implements all restrictions  specific to
that system attribute. This may affect access control  as well  as the
values accepted.


FILESYSTEM IMPLEMENTATION CHOICES
---------------------------------
...


EXT2 EXTENDED ATTRIBUTES
------------------------

Currently,  extended  attributes  are only  supported on  the Extended
Second  (ext2)  Filesystem.  Other  filesystems  may  support extended
attributes in the future.  On ext2,  all attributes  for one  file are
currently limited to one  disk block.  For a  filesystem with  a block
size of 1024 bytes this amounts to  two access  control list  with >50
entries  each  (which  is  more  than  necessary), or  several smaller
objects. All the system security objects will probably fit on one disk
block very easily. The on-disk structures and algorithms  are designed
so that this restriction may be removed later.  Attribute descriptions
and/or  their  values  may  be  moved to  additional disk  blocks when
necessary.

In each ext2 inode, we have the i_file_acl field, reserved  for Access
Control Lists. I have used this field for storing the block  number on
which the extended attributes of an inode are stored instead (ACLs are
stored as extended attributes).

Extended attributes are stored on `plain' disk  blocks, which  are not
part of any files. The disk block layout is similar to the layout used
for  directories.  After  the  attribute  block header,  entry headers
follow.  The  size  of  entry headers  varies with  the length  of the
attribute name.

The attribute values are on the  same block  as their  attribute entry
descriptions, aligned to the end of the  attribute block.  This allows
for additional attributes to be added more easily.

A list of attribute names associated with a file can be retrieved. The
filesystem  handler  returns  a  string  of  names  separated  by null
characters, terminated by two null characters at the end of the list.

The attribute blocks currently not counted in  quotas properly.  If an
extended attribute block  is allocated  for an  inode, this  should be
reflected in the st_blocks field of struct stat (for the stat() system
call).

The mechanism implemented does not scale well to  a massive  number of
attributes. This is no  problem. I  don't see  any reason  for storing
very many attributes for a single inode.


WHY NOT THE ``QUOTA DESIGN''?
-----------------------------
- difficult to retrieve a list of all attributes
- probably slower
- declaring attributes is ugly
+ needs only minimal modifications to filesystems


IMPROVEMENTS
------------
- compact storage of common names uning table lookup (trivial)
- reference counting attribute blocks (requires hashing attribute blocks)
- enlarge size limits


REFERENCES
----------
...


--------------899A113C071253D325A3B707--

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