Thanks for the patch; it definitely helps identify the problem. I don't think it is a completely correct change, however.
The problem is that it's doing the translation in write_xattrs_to_buffer(), but it is not making the translation in the opposite direction in read_xattrs_to_buffer(). This means if some other program using this library function --- for example, fuse2fs, reads in an existing xattr block with an ACL, it will read it the on-disk format, _not_ translate it to a standard acl format, and then write_xattrs_to_buffer() will take as input an acl encoded in the on-disk format, and then try to convert it from lgetxattr format to on-disk format again, and Much Hilarity will result.
I also wonder if write_xattrs_to_buffer() is the right place to make this conversion, or rather ext2fs_{read,write}_ext_attr3(). Then what is stored in the handle structure is the on-disk encoding, and we would do the translation at the higher layer function rather than the low-level read/write functions.
Thanks for the patch; it definitely helps identify the problem. I don't think it is a completely correct change, however.
The problem is that it's doing the translation in write_xattrs_ to_buffer( ), but it is not making the translation in the opposite direction in read_xattrs_ to_buffer( ). This means if some other program using this library function --- for example, fuse2fs, reads in an existing xattr block with an ACL, it will read it the on-disk format, _not_ translate it to a standard acl format, and then write_xattrs_ to_buffer( ) will take as input an acl encoded in the on-disk format, and then try to convert it from lgetxattr format to on-disk format again, and Much Hilarity will result.
I also wonder if write_xattrs_ to_buffer( ) is the right place to make this conversion, or rather ext2fs_ {read,write} _ext_attr3( ). Then what is stored in the handle structure is the on-disk encoding, and we would do the translation at the higher layer function rather than the low-level read/write functions.