Extended attributes

Posted Jan 8, 2019 20:55 UTC (Tue) by nybble41 (subscriber, #55106)
In reply to: Extended attributes by mina86
Parent article: A setback for fs-verity

I'm envisioning something more like openxattrat(int dirfd, const char *path, const char *name, int flags, mode_t mode)—the link to the internal xattr inode would be hidden in the filesystem and you would need at least search access to the file to open the linked xattr inode. User-mode software would never handle the raw inode numbers.

The resulting FD could then be passed as dirfd to openxattrat() (with an empty path) or to flistxattr()/fgetxattr()/fsetxattr() to access the xattrs of the resulting inode, recursively.

Extended attributes

Posted Jan 9, 2019 1:26 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

It sounds like you're reinventing the same design Solaris already created, but with a needleesly different API.

Extended attributes

Posted Jan 10, 2019 4:05 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

I wouldn't say *needlessly* different, since in the Solaris version openat(O_XATTR) can only open attributes for files which are already open, while attropen() lacks a dirfd argument and thus can only use the current working directory for relative paths. My proposed openxattrat() function would basically be attropen() + dirfd. (Perhaps attropenat() would be more fitting?) In general, though, I agree that the concepts are very similar and there is no reason not to adopt the Solaris interface.