<div dir="ltr">On Fri, Sep 22, 2017 at 10:37 AM, Soumya Koduri <span dir="ltr"><<a href="mailto:skoduri@redhat.com" target="_blank">skoduri@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<span class="gmail-"><br>
<br>
On 09/21/2017 07:32 PM, Pierre C wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
Hi All,<br>
<br>
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.<br>
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).<br>
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.<br></span>
I found a draft spec about glusterfs+kerberos <<a href="https://github.com/gluster/glusterfs-specs/blob/master/under_review/Kerberos.md" rel="noreferrer" target="_blank">https://github.com/gluster/gl<wbr>usterfs-specs/blob/master/unde<wbr>r_review/Kerberos.md</a>> but not much more so I think it's not possible with glusterfs right now, correct?<span class="gmail-"><br>
(Also I feel that kerberos would be a bit heavy to manage)<br>
</span></blockquote>
<br>
I am not much familiar with how ssl is handled. But from what I understand from your statement above, you need to restrict root users. Isn't root-squash option enough for it?<br>
<br>
Option: server.root-squash<br>
Default Value: off<br>
Description: Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.<br>
<br>
Option: server.anonuid<br>
Default Value: 65534<br>
Description: value of the uid used for the anonymous user/nfsnobody when root-squash is enabled.<br>
<br>
Option: server.anongid<br>
Default Value: 65534<br>
Description: value of the gid used for the anonymous user/nfsnobody when root-squash is enabled.<br>
<br></blockquote><div><br></div><div>Hi Soumya,</div><div><br></div><div>This is not sufficient because the glusterfs protocol lets the client choose its uid/gid/groups when the client connects to a server. (done there <a href="https://github.com/gluster/glusterfs/blob/master/rpc/rpc-lib/src/auth-glusterfs.c#L177">https://github.com/gluster/glusterfs/blob/master/rpc/rpc-lib/src/auth-glusterfs.c#L177</a> )<br></div><div>So the current implementation relies on the client being trustworthy. A slightly modified client can pretend to be any user.</div><div><br></div><div>Do you see what I mean?</div><div><br></div><div>Cheers,</div><div>Pierre</div><div>eshard<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Soumya<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
---<br>
<br>
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.<br>
The thing that changes is the way client certificates are generated and glusterfsd needs a small patch.<br>
<br></span>
I did an experimental implementation <<a href="https://github.com/eshard/glusterfs/commit/768bf63154fdc59ba67d5788743adab8679ec5ab" rel="noreferrer" target="_blank">https://github.com/eshard/glu<wbr>sterfs/commit/768bf63154fdc59b<wbr>a67d5788743adab8679ec5ab</a>> of this idea. Custom fields "1.2.3.4.5.6.7" and "1.2.3.4.5.6.8" are used for uid and gid.<span class="gmail-"><br>
I tried it with custom CA trusted by all bricks and I issued a few client certificates.<br></span>
No server configuration is needed when a new client is added, when a client is revoked the a CRL <<a href="https://en.wikipedia.org/wiki/Certificate_revocation_list" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Certificate_revocation_list</a>> must updated and pushed to all servers.<span class="gmail-"><br>
By the way I didn't get glusterfs servers to accept my CRLs, do some people use it?<br>
<br>
Notes:<br>
* 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.<br>
* Clients obviously can't modify their certificates because they are signed by CA<br>
<br>
What do you think of this implementation, is it safe?<br></span>
Do all client operationsuse auth_glusterfs_v2_authenticate or did I miss other codepaths?<span class="gmail-"><br>
<br>
Thanks!<br>
<br>
Pierre Carru<br>
eshard<br>
<br>
PS: By the way I found the source code very clean and well organized, nice job :)<br>
<br>
<br></span>
______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
<br>
</blockquote>
</blockquote></div><br></div></div>