Linux Kernel Architecture

Chapter 11: Extended Attributes and Access Control Lists

Delegate decision to security module

Yes

No

security namespace?

vfs_setxattr

xattr_permission

setxattr available? setxattr

fsnotify_xattr

Figure 11-3: Code flow diagram forvfs_setxattr.

At first, the kernel needs to make sure that the user is privileged to perform the desired operation; the
choice is made byxattr_permission. For Read-Only or immutable inodes, the operation fails immedi-
ately; otherwise, the following checks are performed:

fs/xattr.c

static int

xattr_permission(struct inode *inode, const char *name, int mask)

{

...

/*

* No restriction for security.* and system.* from the VFS. Decision

* on these is left to the underlying file system / security module.

*/

if (!strncmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN) ||

!strncmp(name, XATTR_SYSTEM_PREFIX, XATTR_SYSTEM_PREFIX_LEN))

return 0;

/*

* The trusted.* namespace can only accessed by a privileged user.

*/

if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN))

return (capable(CAP_SYS_ADMIN)? 0 : -EPERM);

/* In user.* namespace, only regular files and directories can have

* extended attributes. For sticky directories, only the owner and

* privileged user can write attributes.

*/

if (!strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN)) {

if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode))

return -EPERM;

if (S_ISDIR(inode->i_mode) && (inode->i_mode & S_ISVTX) &&

(mask & MAY_WRITE) && !is_owner_or_cap(inode))

return -EPERM;

}

return permission(inode, mask, NULL);

}

The VFS layer does not care about attributes that live in thesecurityorsystemnamespace. Note
that the request isgrantedif 0 is returned as result ofxattr_permission! The kernel ignores these