Extended attributes

Posted Jan 8, 2019 15:41 UTC (Tue) by mina86 (guest, #68442)
In reply to: Extended attributes by himi
Parent article: A setback for fs-verity

If I understand you correctly, you’re suggesting a iopen(int inode, int flags, mode_t mode) syscall. If that’s the case, the problem is that it would allow bypassing filesystem permissions. Namely, it would render execution bit of a directory useless since user would be able to read a world-readable file even if it resides in directory they have no access to.

to post comments

Extended attributes

Posted Jan 8, 2019 20:55 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (2 responses)

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.