Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values

[Sergio Gelato]

Package: libglib2.0-0
Version: 2.58.3-2+deb10u2
Severity: important

g_file_copy_attributes(), when invoked with G_FILE_COPY_ALL_METADATA on
files in NFS, is prone to truncating the value of extended attribute
system.nfs4_acl. Here is an excerpt from strace output, showing the
getxattr() and setxattr() calls:

getxattr("/home/xxx/a", "system.nfs4_acl", 0x7ffef8b54a20, 63) = -1 ERANGE (Numerical result out of range)
getxattr("/home/xxx/a", "system.nfs4_acl", NULL, 0) = 80
getxattr("/home/xxx/a", "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80) = 80
setxattr("/home/xxx/b", "system.nfs4_acl", "", 0, 0) = -1 EIO (Input/output error)

Note how the attribute value was truncated from 80 bytes to 0. I believe this
is because the value starts with a 0 byte. gio/glocalfileinfo.c:escape_xattr()
does not make use of the len argument when computing escaped_val, but instead
invokes strlen() which is unsuitable for binary strings. A look at the latest
upstream version, 2.64.3, suggests the problem is still there.

This impacts such operations as "Save As" in evince.

Due to an unrelated bug I recommend running a recent kernel (e.g., 5.5 rather
than 4.19) when attempting to reproduce this problem.