Chapter 11: Extended Attributes and Access Control Lists
Generic HandlerFunctions
Security is an important business. If wrong decisions are made, then the best security mechanisms are
worth nothing. Since duplicating code increases the possibility of getting details wrong, the kernel
provides generic implementations of theinode_operationmethods for extended attribute handling
on which filesystem writers can rely. As an additional benefit, this allows the filesystem people to be
lazy — and concentrate their talents on things that matter much more to them than getting each and
every security corner case right. The following examples look at these default implementations. As
before, the code for different types of access is very similar, so the implementation ofgeneric_setxattr
is discussed first and the differences of the other methods afterward.Let’s get right down into the code:fs/xattr.c
int
generic_setxattr(struct dentry dentry, const char name, const void value, size_t size, int
flags)
{
struct xattr_handler handler;
struct inode *inode = dentry->d_inode;
if (size == 0)
value = ""; / empty EA, do not remove /
handler = xattr_resolve_name(inode->i_sb->s_xattr, &name);
if (!handler)
return -EOPNOTSUPP;
return handler->set(inode, name, value, size, flags);
}
First,xattr_resolve_namefinds the instance ofxattr_handlerthat is apt for the namespace of
the extended attribute in question. If a handler exists, thesetmethod is called to perform the
desired set operation. Obviously, there cannot be any further generic step;handler->setmust
be a filesystem-specific method (the implementation of these methods for Ext3 is discussed in
Section 11.1.2).It is also not difficult to find the proper handler:fs/xattr.c
static struct xattr_handler *
xattr_resolve_name(struct xattr_handler **handlers, const char **name)
{
...
for_each_xattr_handler(handlers, handler) {
const char *n = strcmp_prefix(*name, handler->prefix);
if (n) {
*name = n;
break;
}
}
return handler;
}