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
Received on Fri Mar 5 13:52:16 2010