Linux Kernel Architecture

(Jacob Rumans) #1

Chapter 11: Extended Attributes and Access Control Lists


Victory can seem to be beguilingly close when a granting entry has been found, but the hopes are quickly
annihilated when anACL_MASKentry denies the access.

The following code snippet ensures that not only the rights are valid because of a proper UID or GID,
but also that the desired access (read, write, or execute) is allowed by the granting entry:

fs/posix_acl.c
...
check_perm:
if ((pa->e_perm & want) == want)
return 0;
return -EACCES;
}

11.2.2 Implementation in Ext3


Since ACLs are implemented on top of extended attributes and with the aid of many generic helper
routines as discussed above, the implementation in Ext3 is quite concise.

Data Structures


The on-disk representation format for an ACL is similar to the in-memory representation required by the
generic POSIX helper functions:

fs/ext3/acl.h
typedef struct {
__le16 e_tag;
__le16 e_perm;
__le32 e_id;
} ext3_acl_entry;

The meaning of the struct members is identical to the meaning discussed above for the in-memory vari-
ant. To save disk space, a version without thee_idfield is also defined. It is used for the first four entries
of an ACL list because no specific UID/GID is required for them:

fs/ext3/acl.h
typedef struct {
__le16 e_tag;
__le16 e_perm;
} ext3_acl_entry_short;

A list of ACL entries is always led by a header element, which is defined as follows:

fs/ext3/acl.h
typedef struct {
__le32 a_version;
} ext3_acl_header;

Thea_versionfield would allow for distinguishing between different versions of the ACL implemen-
tation. Fortunately, the current implementation has not yet shown any weaknesses that would require
introducing a new version, so revisionEXT3_ACL_VERSION)—0x0001— is still perfectly fine. Although
Free download pdf