Linux Kernel Architecture

Chapter 11: Extended Attributes and Access Control Lists

namespaces and delegates the choice to security modules that are included via numerous security-related

calls,security_*, found everywhere in the kernel, or the underlying filesystem.

However, the VFS layer is concerned about thetrustednamespace. Only a sufficiently privileged user

(i.e., root or a user with appropriate capabilities) isallowed to perform operations on such attributes. For

a change, the comments in the source code state precisely how the kernel thinks that attributes from the

usernamespace should be taken care of, so I need not add anything further.

Any decision for attributes from a different namespace from those processed until now is deferred to

the genericpermissionfunction as discussed in Section 8.5.3. Note that this includes ACL checks that

are implemented with the aid of extended attributes; how these checks are implemented is discussed in

Section 11.2.2.

If the inode passed the permission check,vfs_setxattrcontinues as follows:

1. If a filesystem-specificsetxattrmethod is available in the inode operations, it is called to
   perform the low-level interaction with the filesystem. After this,fsnotify_xattruses the
   inotify mechanism to inform the userland about the extended attribute change.


2. If nosetxattrmethod is available (i.e., if the underlying filesystem does not support
   extended attributes), but the extended attribute in question belongs to thesecuritynames-
   pace, then the kernel tries to use a function that can be provided by security frameworks like
   SELinux. If no such framework is registered, the operation is denied.
   This allows security labels on files that reside on filesystems without extended attribute sup-
   port. It is the task of the security subsystem to store the information in a reasonable way.

Note that some more hook functions of the security framework are called during the extended attribute

system calls. They are omitted here since if no extra security framework like SELinux is present, they will

have no effect.

Since the implementation for the system callsgetxattrandremovexattrnearly completely follows the

scheme presented forsetxattr, it is not necessary to discuss them in greater depth. The differences are

as follows:

❑ getxattrdoes not need to use fnotify because nothing is modified.

❑ removeattrneed not copy an attribute value, but only the name from the userspace. No special

casing for the security handler is required.

The code for listing all extended attributes associated with a file differs more from this scheme, particu-

larly because no functionvfs_listxattris used. All work is performed inlistxattr. The implementa-

tion proceeds in three easy steps:

1. Adapt the maximum size of the list as given by by the userspace program such that it is
   not higher than the maximal size of an extended attribute list as allowed by the kernel with
   XATTR_LIST_MAX, and allocate the required memory.


2. Calllistxattrfrominode_operationsto fill the allocated space with name/value pairs.


3. Copy the result back to the userspace.