On Oct 21, 2014 9:59 PM, "Seth Forshee" <seth.forshee@xxxxxxxxxxxxx> wrote: > > On Tue, Oct 21, 2014 at 02:27:13PM -0700, Andy Lutomirski wrote: > > On Tue, Oct 21, 2014 at 2:21 PM, Seth Forshee > > > > > return s; > > > > > > fail: > > > diff --git a/fs/xattr.c b/fs/xattr.c > > > index 64e83efb742d..383bb9f25555 100644 > > > --- a/fs/xattr.c > > > +++ b/fs/xattr.c > > > @@ -40,6 +40,12 @@ xattr_permission(struct inode *inode, const char *name, int mask) > > > return -EPERM; > > > } > > > > > > + /* Restrict security.* and trusted.* to mounts from init_user_ns. */ > > > + if (inode->i_sb->s_user_ns != &init_user_ns && > > > + (!strcmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN) || > > > + !strcmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN))) > > > + return -EPERM; > > > + > > > > trusted.* should be fine already, I think -- it checks global > > capabilities. And I still think that security.* should be left to > > LSMs, which IMO really do need to be fixed for user namespaces. > > > > But how does this help with FUSE at all? Does FUSE end up calling > > xattr_permission? > > It gets called from vfs_getxattr, and thus for the getxattr syscall for > all fs types, so this would block reading any trusted.* xattrs from the > fuse userspace process. Oh. It seems weird to me that getxattr would get an error instead of FUSE being prevented from setting those attributes. I'm still unconvinced that this is the right approach. And anything that tries to use LSMs in a container will eventually want those attributes. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
