On Tue, 2006-02-07 at 22:44 -0500, Bill Nottingham wrote: > 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. SELinux xattrs are _always_ supported for every filesystem by definition, because their values are actually provided by the SELinux module. All data must be labeled. > Can you, in userspace, remove xattrs? No. Removal of SELinux xattrs (or more generally, MAC labels) is not allowed, even for conventional filesystems like ext3, as long as SELinux is operating/enabled. No unlabeled data. > > 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. I think you need to look at the history here: We started with our own APIs for SELinux separate from the xattr API, but were told to migrate to using the xattr API for upstream merging of SELinux into Linux 2.6. We then individually patched various filesystems like tmpfs and devpts on an as-needed basis to support the security xattrs, but the real processing for such filesystems simply consisted of calling back into the SELinux module to get/set the incore inode security information. For LSPP (and as a widely desired functional enhancement by people who wanted to see labels on other filesystems like /proc and were used to being able to do that with the old SELinux), we needed to support at least the ability to get the security attributes on all filesystem types (and to get the actual security attribute as seen by SELinux, including for filesystems labeled via context mounts, genfs_contexts, etc). So we introduced a generic fallback for security xattrs in the VFS in 2.6.14 so that we didn't need to patch every filesystem type, and then we introduced support for canonicalization of getxattr results in 2.6.15 so that userspace could see the same label being used actively by SELinux. > > 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... Over on redhat-lspp, during early discussions of polyinstantiated directories and potential use of unionfs there, Viro said that unionfs was nowhere near ready for merging and had a lot of nasty corner cases. > > > > 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. Not sure what issue you are encountering with using vfs_getxattr; nfsd uses it. For listxattr, introducing a vfs_listxattr should be straightforward and reasonable if there is a user for it; I think the absence is just due to a lack of a user. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
