Setting extended attributes failed, reason: Operation not permitted

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.