linux-ext4 - xfstests #62 broken on ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1QsFMR-0001iq-Vt@tytso-glaptop>
Date:	Sat, 13 Aug 2011 10:38:51 -0400
From:	"Theodore Ts'o" <tytso@....edu>
To:	linux-ext4@...r.kernel.org, xfs@....sgi.com
cc:	Stefan Behrens <sbehrens@...ntdisaster.de>
Subject: xfstests #62 broken on ext4


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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html