Xfstests #62 was recently enabled by commit b2b36d0a4.
However, this test is failing for ext4 because ext4 doesn't support
extended attributes on anything other than regular files and
directories. This is behavior is documented in the attr(5) man page:
Extended user attributes
Extended user attributes may be assigned to files and directories for
storing arbitrary additional information such as the mime type, charac‐
ter set or encoding of a file. The access permissions for user
attributes are defined by the file permission bits.
The file permission bits of regular files and directories are inter‐
preted differently from the file permission bits of special files and
symbolic links. For regular files and directories the file permission
bits define access to the file's contents, while for device special
files they define access to the device described by the special file.
The file permissions of symbolic links are not used in access checks.
These differences would allow users to consume filesystem resources in
a way not controllable by disk quotas for group or world writable spe‐
cial files and directories.
For this reason, extended user attributes are only allowed for regular
files and directories, and access to extended user attributes is
restricted to the owner and to users with appropriate capabilities for
directories with the sticky bit set (see the chmod(1) manual page for
an explanation of Sticky Directories).
... and it is enforced by the generic fs/xattr.c code in
xattr_permission():
/*
* In the user.* namespace, only regular files and directories can have
* extended attributes. For sticky directories, only the owner and
* privileged users 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 (mask & MAY_WRITE) ? -EPERM : -ENODATA;
if (S_ISDIR(inode->i_mode) && (inode->i_mode & S_ISVTX) &&
(mask & MAY_WRITE) && !inode_owner_or_capable(inode))
return -EPERM;
}
It looks like XFS is not conformant to documented behaviour and the file
system generic code. The question is how should we fix this? I can
think of a couple of different options
(1) Back out commit b2b36d0a4 and make test #62 XFS-specific again.
(2) Option #1, above, and then also create another test for file systems
with the standard/generic Linux behavior
(3) Modify test #62 so that it can support both the XFS and Linux
generic behavior.
(4) Change the generic code to match what XFS does (despite the design
rationale mentioned in the attr(5) man page).
(5) Change XFS to match the generic behavior, and then change test #62.
What do people think?
- Ted
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
