Skip to contentSkip to conversation

Fix listxattr() for generic security attributes

PATCH In review Daniel Drake 3 participants 3 messages Dec 8, 2005 VFS

lore
Share & tools
lore

Daniel Drake

author
#0 lore raw

PATCH 1/1 Fix listxattr() for generic security attributes

Commit f549d6c18c0e8e6cf1bf0e7a47acc1daf7e2cec1 introduced a generic fallback for security xattrs, but appears to include a subtle bug.

Gentoo users with kernels with selinux compiled in, and coreutils compiled with acl support, noticed that they could not copy files on tmpfs using 'cp'.

cp (compiled with acl support) copies the file, lists the extended attributes on the old file, copies them all to the new file, and then exits. However the listxattr() calls were failing with this odd behaviour:

llistxattr("a.out", (nil), 0) = 17
llistxattr("a.out", 0x7fffff8c6cb0, 17) = -1 ERANGE (Numerical result out of range)

I believe this is a simple problem in the logic used to check the buffer sizes; if the user sends a buffer the exact size of the data, then its ok :)

This patch solves the problem. Please apply for 2.6.15. More info can be found at http://bugs.gentoo.org/113138

Signed-off-by Daniel Drake <[email protected]>
fs/xattr.c renamed from fs/xattr.c.orig +1 -1
@@ -243,7 +243,7 @@ listxattr(struct dentry *d, char __user 
 		error = d->d_inode->i_op->listxattr(d, klist, size);
 	} else {
 		error = security_inode_listsecurity(d->d_inode, klist, size);
-		if (size && error >= size)
+		if (size && error > size)
 			error = -ERANGE;
 	}
 	if (error > 0) {
Acked-by on v1 1/1
#1 lore raw
Quoted 14 lines · Daniel Drake

Commit f549d6c18c0e8e6cf1bf0e7a47acc1daf7e2cec1 introduced a generic fallback for security xattrs, but appears to include a subtle bug.

Gentoo users with kernels with selinux compiled in, and coreutils compiled with acl support, noticed that they could not copy files on tmpfs using 'cp'.

cp (compiled with acl support) copies the file, lists the extended attributes on the old file, copies them all to the new file, and then exits. However the listxattr() calls were failing with this odd behaviour:

llistxattr("a.out", (nil), 0) = 17
llistxattr("a.out", 0x7fffff8c6cb0, 17) = -1 ERANGE (Numerical result out of range)

Quoted 7 lines

I believe this is a simple problem in the logic used to check the buffer sizes; if the user sends a buffer the exact size of the data, then its ok :)

This patch solves the problem. Please apply for 2.6.15. More info can be found at http://bugs.gentoo.org/113138

Signed-off-by Daniel Drake <[email protected]>
Acked-by Stephen Smalley <[email protected]>
Signature · 2 lines
Stephen Smalley
National Security Agency
Acked-by on v1 1/1
#2 lore raw
In reply to Daniel Drake
Quoted 14 lines · Daniel Drake

Commit f549d6c18c0e8e6cf1bf0e7a47acc1daf7e2cec1 introduced a generic fallback for security xattrs, but appears to include a subtle bug.

Gentoo users with kernels with selinux compiled in, and coreutils compiled with acl support, noticed that they could not copy files on tmpfs using 'cp'.

cp (compiled with acl support) copies the file, lists the extended attributes on the old file, copies them all to the new file, and then exits. However the listxattr() calls were failing with this odd behaviour:

llistxattr("a.out", (nil), 0) = 17
llistxattr("a.out", 0x7fffff8c6cb0, 17) = -1 ERANGE (Numerical result out of range)

Quoted 7 lines

I believe this is a simple problem in the logic used to check the buffer sizes; if the user sends a buffer the exact size of the data, then its ok :)

This patch solves the problem. Please apply for 2.6.15. More info can be found at http://bugs.gentoo.org/113138

Signed-off-by Daniel Drake <[email protected]>
Acked-by James Morris <[email protected]>
Signature · 2 lines
James Morris
<[email protected]>