[Gluster-users] Restrict root clients / experimental patch

Pierre C pierre.carru at gmail.com
Thu Sep 21 14:02:22 UTC 2017

Hi All,

I would like to use glusterfs in an environment where storage servers are
managed by an IT service - myself :) - and several users in the
organization can mount the distributed fs. The users are root on their
As far as I know about glusterfs, a root client user may impersonate any
uid/gid since it provides its uid/gid itself when it talks to the bricks
(like nfsv3).
The thing is, we want to enforce permissions, i.e. user X may only access
files shared with him even if he's root on his machine.
I found a draft spec about glusterfs+kerberos
but not much more so I think it's not possible with glusterfs right now,
(Also I feel that kerberos would be a bit heavy to manage)


An simple hack that I found is to add custom uid/gid fields in clients' ssl
certificates. The bricks use the client's uid/gid specified in its
certificate rather than using one specified by the user. This solution has
no effect on performance and there's no need for a central authentication.
The thing that changes is the way client certificates are generated and
glusterfsd needs a small patch.

I did an experimental implementation
of this idea. Custom fields "" and "" are used
for uid and gid.
I tried it with custom CA trusted by all bricks and I issued a few client
No server configuration is needed when a new client is added, when a client
is revoked the a CRL
<https://en.wikipedia.org/wiki/Certificate_revocation_list> must updated
and pushed to all servers.
By the way I didn't get glusterfs servers to accept my CRLs, do some people
use it?

 * groups are not handled right now and since users may change groups
regularly I don't think it would be a great idea to freeze them in a
certificate. The bricks could possibly do an ldap lookup in order to
retrieve and cache the groups for an uid.
 * Clients obviously can't modify their certificates because they are
signed by CA

What do you think of this implementation, is it safe?
Do all client operations use auth_glusterfs_v2_authenticate or did I miss
other codepaths?


Pierre Carru

PS: By the way I found the source code very clean and well organized, nice
job :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170921/4fdc349c/attachment.html>

More information about the Gluster-users mailing list