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