https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216127
Conrad Meyer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Conrad Meyer <[email protected]> --- The kernel code (e.g. ffs_findextattr) indicates that EA names are not, in fact, nul-terminated. So the headers restore uses are wrong, as is the restore code. This piece of kernel code hasn't changed substantially since the early 2000s. The misleading header comment and macros that reference ea_name as if it is a nul-terminated string were introduced in 2007 in r167010. It immediately precedes r167011, which introduced extattr support to restore. ea_name will *happen* to be nul-terminated when ea_namelength % 8 == 1, like in your "m" example. This is because `sizeof(uint32_t) + 3 * sizeof(uint8_t) + strlen(ea_name)` is padded to multiples of 8 bytes, and the padding is always zeroed. Well, there's a long time between ~2002 and 2007. Maybe Kirk just forgot that ea_name wasn't nul-terminated, or didn't try any keys with length == 1 (mod 8). I propose the following actions: * Fix the ufs/extattr.h documentation for ea_name, and remove EXTATTR_SET_LENGTHS macro (unused) entirely (it uses strlen(ea_name)) * Fix accompanying documentation in extattr.9, fs.5. * Merge set_extattr_file(), set_extattr_link(), and set_extattr_fd() in restore and fix uses of ea_name that assume nul-termination. * Finally, perform the simplification that was proposed in the r167010 commit log. I'll draw up some patches. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "[email protected]"
