Hi all,
Trying to install gluster replied that kind of error message when I execute the gluster volume create volume1 replica 2 command.
Setting extended attributes failed, reason: Operation not permitted
I have searched on the net and forums but every answer pointed out that defining privileged containers solved the problem. My question is, is there any way to run gluster without privileged container?
Regards.
Unprivileged users aren’t allow to set most extended attributes for security reasons.
So privileged may indeed be the way around this as potentially problematic as that may be.
In theory we could extend our syscall interception support a policy for additional xattrs. It’d still be a bit dangerous but it’d be up to the admin to decide what xattrs can be used.
Do you know what xattrs are used for this?
Frankly, I dont know much about filesystem internals but as stated in that article, trusted.glusterfs.dht and trusted.afr.* xattrs are enought to bypass the installation.
Regards.
http://oliviercontant.com/gluster-glusterfs-extended-attribute/
Ah yeah, trusted.* is indeed restricted to real root usually.
@brauner think we can do a security.syscalls.intercept.setxattr.custom that would take a comma separate listed of xattrs to intercept and allow?
Hm, I wouldn’t make it that flexible. Maybe we should have allowed namespaces, i.e. introduce:
security.syscalls.intercept.setxattr.trusted.<attr>
and then later
security.syscalls.intercept.setxattr.security.<attr>
we’d basically be piggy-backing on the existing xattr namespaces?
That’d include a crap ton of individual LXD config keys though.
Having one key that can be set to a comma separate list of xattrs to allow seems far more manageable.
Obviously people can shoot themselves in the foot with this, but that’s not a key we’d ever allow untrusted users to set, so not a real issue.
Just to clarify, I meant only adding the namespace. not the individual keys, i.e. add
security.syscalls.intercept.setxattr.security
but sure if you prefer the maximum flexibility
Though that might mean a ton of parsing including binary stuff so I don’t know.
How so, aren’t all the keys just a clear text string?
The value can be random binary crap, but we shouldn’t really need to parse that, just copy the value provided by the user.
I don’t think that allowing an entire namespace is going to be all that useful as I certainly wouldn’t want to allow all of trusted or all of security but some specific keys within those I may be fine with.
Sorry for digging this thread again but, changing some of the parameters of the container like that.
indiana@mars:~$ lxc config show gfs01
architecture: x86_64
config:
image.architecture: amd64
image.description: Ubuntu focal amd64 (20211204_07:42)
image.os: Ubuntu
image.release: focal
image.serial: "20211204_07:42"
image.type: squashfs
image.variant: cloud
security.nesting: "true"
security.syscalls.intercept.mount: "yes"
security.syscalls.intercept.mount.allowed: glusterfs
security.syscalls.intercept.setxattr: "true"
volatile.base_image: 46e482c4f0751c16f90b9225d3ca6bc62774adf5cbfa631c1ec5918ba37b12af
volatile.eth0.host_name: veth16022bb1
volatile.eth0.hwaddr: 00:16:3e:82:25:5a
volatile.idmap.base: "0"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.last_state.power: RUNNING
volatile.uuid: 4a751fee-4747-4ae7-b1c3-eb0e2cc0c84d
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""
When I restarted the container I get the following messages.
t=2021-12-04T21:13:15+0300 lvl=dbug msg="Syscall handler received fds 20(/proc/<pid>), 21(/proc/<pid>/mem), and 32([seccomp notify])"
t=2021-12-04T21:13:15+0300 lvl=dbug msg="Handling mount syscall" audit_architecture=3221225534 container=gfs01 data="mode=755" fstype=tmpfs project=default seccomp_notify_fd=32 seccomp_notify_flags=0 seccomp_notify_id=3054852692903493342 seccomp_notify_mem_fd=21 seccomp_notify_pid=153309 source=tmpfs syscall_continue=true syscall_number=165 target=/tmp/namespace-dev-Fha9eA/dev
t=2021-12-04T21:13:15+0300 lvl=dbug msg="Send seccomp notification for id(3054852692903493342)"
I suppose seccomp complain about some of the syscalls, how can I intercept the system calls? Can someone assist me?
Regards.
Those are just debug trace messages, I don’t see any errors there.
When I execute the gluster volume create test replica 2 transport tcp gfs01:/brick/test gfs02:/brick/test force, it response that message.
volume create: test: failed: Glusterfs is not supported on brick: gfs01:/brick/test.
Setting extended attributes failed, reason: Operation not permitted.
Do I need to intercept any other paremeters or how can I find which syscalls are used for glusterfs?
Regards.
A little bit searching I suppose I found that link, https://bugzilla.redhat.com/show_bug.cgi?id=764245. And there is a workaround in that bug report,
http://serverfault.com/questions/29615/how-to-mount-glusterfs-inside-a-openvz-container
If I get the bug report correctly, is there any chance to change the /dev/fuse node with root permission, in container it looks like that.
root@gfs01:~# ls -alh /dev/fuse
crw-rw-rw- 1 nobody nogroup 10, 229 Dec 5 19:15 /dev/fuse
Regards.
I don’t see how file ownership is relevant on a file which is world writable like this one.
Yes, you are right. So what about that sentence, can it be done in the container and how?
One approach would be to allow using user extended attributes (with config or command-line option)
Regards.