On Wed, Mar 03, 2010 at 06:28:24PM +0000, Ed W wrote: > Hi, I could use some help figuring out how to mount a fuse filesystem > under a vserver > The goal is to use glusterfs as a server from within a vserver (will > eventually want it as a client also) > A "working" configuration is simply to add SYS_ADMIN to bcapabilities > Instead I tried adding to ccapabilities: > SECURE_MOUNT > SECURE_REMOUNT > BINARY_MOUNT > FS_SECURITY > This doesn't work and glusterfs gives the following error: > [2010-03-03 18:19:50] C [posix.c:4876:init] brick: Extended attribute > not supported, exiting. > strace shows: > stat("/mnt/gluster-export", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > lsetxattr("/mnt/gluster-export", "trusted.glusterfs.test", "working", 8, > 0) = -1 EPERM (Operation not permitted) this is interesting, on a recent Linux-VServer kernel (besides the fact that I have missed a check for the security attribute alteration - will be in the next patch :) I see the following checks on your way: user_lpath()->do_path_lookup() unlikely mnt_want_write() should be fine if you can write :) setxattr() filesystem specific/assuming generic xattr_resolve_name() -> handler (fs specific) generic_acl_set() -> is_owner_or_cap() which checks for ownership or capable(CAP_FOWNER) > Can anyone please help with a suggestion on what capabilities will let > my guest run lsetxattr here? "trusted" seems to be handled special with the following check: if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) return (capable(CAP_SYS_ADMIN) ? 0 : -EPERM); so you need to have CAP_SYS_ADMIN inside the guest for now to create or modify the 'trusted' namespace ... let me know if you want to do some testing with a FS_TRUSTED flag ... best, Herbert > Kernel: 2.6.32.8-grsec2.1.14-vs2.3.0.36.29.1 > Thanks > Ed W