<div dir="ltr"><div><div><div><div><div>Hi All,</div><div><br></div><div>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 machines.</div><div>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).</div><div>The thing is,  we want to enforce permissions, i.e. user X may only access files shared with him even if he&#39;s root on his machine.</div><div>I found a draft spec about <a href="https://github.com/gluster/glusterfs-specs/blob/master/under_review/Kerberos.md">glusterfs+kerberos</a> but not much more so I think it&#39;s not possible with glusterfs right now, correct?</div><div>(Also I feel that kerberos would be a bit heavy to manage)<br></div><div><br></div><div>---</div><div><br></div><div>An simple hack that I found is to add custom uid/gid fields in clients&#39; ssl certificates. The bricks use the client&#39;s uid/gid specified in its certificate rather than using one specified by the user. This solution has no effect on performance and there&#39;s no need for a central authentication.</div><div>The thing that changes is the way client certificates are generated and glusterfsd needs a small patch.</div><div><br></div><div>I did an <a href="https://github.com/eshard/glusterfs/commit/768bf63154fdc59ba67d5788743adab8679ec5ab">experimental implementation</a> of this idea. Custom fields &quot;<span class="gmail-blob-code-inner"><span class="gmail-pl-s">1.2.3.4.5.6.7&quot; and &quot;</span></span><span class="gmail-blob-code-inner"><span class="gmail-pl-s"><span class="gmail-blob-code-inner"><span class="gmail-pl-s">1.2.3.4.5.6.8<span class="gmail-pl-pds">&quot; are used for uid and gid.<br></span></span></span></span></span></div><div>I tried it with custom CA trusted by all bricks and I issued a few client certificates.</div><div>No server configuration is needed when a new client is added, when a client is revoked the a <a href="https://en.wikipedia.org/wiki/Certificate_revocation_list">CRL</a> must updated and  pushed to all servers.</div><div>By the way I didn&#39;t get glusterfs servers to accept my CRLs, do some people use it?<br></div><div><br></div>Notes:</div><div><div> * groups are not handled right now and since users may change groups regularly I don&#39;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.<br></div> * Clients obviously can&#39;t modify their certificates because they are signed by CA</div></div><div><br></div><div>What do you think of this implementation, is it safe?<br></div><div>Do all client operations<span class="gmail-blob-code-inner"><span class="gmail-pl-en"> use auth_glusterfs_v2_authenticate or did I miss other codepaths?</span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-en"><br></span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-en">Thanks!<br></span></span></div><br></div>Pierre Carru<br></div>eshard<br><br><div><span class="gmail-blob-code-inner"><span class="gmail-pl-en">PS: By the way I found the source code very clean and well organized, nice job :)<br></span></span></div></div>