James Morris (jmorris@xxxxxxxxx) said: > > This means that anything on tmpfs can have a xattr retrieved from userspace > > just fine with getxattr(2), but if you try and get it in the kernel via > > 'normal' means (such as the inode's getxattr method), it will fail. This > > breaks tmpfs as part of a unionfs branch pretty badly. > > > > Why was xattrs-on-tmpfs done this way? It seems somewhat hackish. > > So xattrs do not have to be implemented for every type of psudo fs. Well, yes, but it means the xattrs implemented for these pseudo fses are somewhat incomplete, if not broken. Can you, in the kernel, easily check to see if xattrs are supported for a filesystem? No. Can you, in userspace, remove xattrs? No. It just seems like a hacky interface to say "filesystems need to provide their own xattr code, but if they don't the security module might decide to make one up." It would seem preferable to just have the security labels be done via an explicit mechanism rather than to incompletely overload xattrs. > What is the upstream status of unionfs? It's not upstream yet, although it's used in a variety of projects. Moreover, trying to fix it to work around this, doesn't work, as... > > I could theoretically patch unionfs to call the vfs method, but... ew. listxattr isn't exported as a vfs method, and even just using the vfs_get/setxattr methods doesn't appear to work correctly. Bill -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
