Racy extended attributes querying.

[verygreen]

While doing some unrelated stracing in #905 I noticed that the EA querying is racy and also suboptimal:

lstat("/mnt/test/1019429875\n", {st_mode=S_IFREG, st_size=16, ...}) = 0
open("/mnt/test/1019429875\n", O_RDONLY|O_NOATIME|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG, st_size=16, ...}) = 0
fstat(5, {st_mode=S_IFREG, st_size=16, ...}) = 0
ioctl(5, TCGETS, 0x7ffc41602cd0)        = -1 ENOTTY (Inappropriate ioctl for device)
fstat(5, {st_mode=S_IFREG, st_size=16, ...}) = 0
lseek(5, 0, SEEK_CUR)                   = 0
read(5, "\363C\303<\0\0\0\00010194298", 8388608) = 16
fadvise64(5, 0, 16, POSIX_FADV_DONTNEED) = 0
close(5)                                = 0
llistxattr("/mnt/test/1019429875\n", NULL, 0) = 0
getxattr("/mnt/test/1019429875\n", "system.posix_acl_access", 0x0, 0) = -1 ENODATA (No data available)
getxattr("/mnt/test/1019429875\n", "system.posix_acl_default", 0x0, 0) = -1 ENODATA (No data available)

llistxattr is racy and should be flistxattr BEFORE we close the file to be 100% sure the data and attributes are from the same file.
getxattr is even more wrong as it would not work correctly on symlinks too, reading the attrs from the symlink target, not symlink itself besides the actual race.

[verygreen]

The suboptimallness is in doing llistxattr, and then even despite it returning empty list, still trying to fetch some extended attributes that we now know are not really there. (hm, is this just a platform-dependent thing and on other OSes listxattr would not return ACLs and the like?)

[enkore]

Borg has generic xattr support (i.e. it listxattrs all attrs, then saves them), but also specific support for ACLs which are queried separately via libacl / acl_XXX functions -- those are making the getxattr system.posix_acl_default etc. calls.

[enkore]

A related race is found in xattr.get_all: https://github.com/borgbackup/borg/blob/1.0-maint/borg/xattr.py#L28

When a single xattr vanishes between listxattr and getxattr of the respective xattr, OSError(errno=ENOATTR|ENODATA) will be raised and processing of the file will be aborted/skipped.

However only the attribute should be skipped.

[ThomasWaldmann]

@enkore the issue you have noted right above is fixed in PR #1464.

[enkore]

Moved the second issue (#906 (comment)) to #1469, since it's a different problem.