<div dir="ltr"><div class="gmail_extra">You are right. Failing just a GETSPEC would still allow client to connect to the volume directly when by using a volfile. We can prevent this by also setting 'auth.reject *' on the volume. The username/password based authentication has higher priority than auth.reject or auth.allow, so all the trusted clients within the pool would still be able to connect to the bricks and do their job.</div><div class="gmail_extra"><br></div><div class="gmail_extra">~kaushal</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 23, 2015 at 2:21 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Jan 22, 2015 at 08:40:30PM +0530, Deepak Shetty wrote:<br>
> I didn't understand how the brick process point is relevant here ? Can you<br>
> elaborate pls ?<br>
> If we are failing the GETSPEC itself there shouldn't be any question of<br>
> client connecting to the brick process, no ?<br>
><br>
> I don't have much insights into the code but I am just thinking logically<br>
> and saying the above<br>
<br>
</span>Well, failing the GETSPEC will prevent the standard usage from<br>
connecting to the bricks. But, in case the client uses a .vol file<br>
directly, GETSPEC is not used (I assume, but could be wrong). </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Because a .vol file can contain the 'trusted' credentials, I am of the<br>
opinion that when 'disabling' the GlusterFS protocol, the bricks should<br>
only accept connections with those trusted credentials.<br>
<br>
That way self-heal and all can still do their work (they run inside the<br>
Trusted Pool that receives the trusted credentials with GETSPEC).<br>
<br>
Clients that still have an old .vol file will be denied access, because<br>
those clients were not in the Trusted Pool and hence do not have the<br>
trusted credentials.<br>
<br>
Is is it a little clearer with this example? If not, let me know :)<br>
<span class=""><font color="#888888"><br>
Niels<br>
</font></span><div class=""><div class="h5"><br>
><br>
> thanx,<br>
> deepak<br>
><br>
><br>
> On Wed, Jan 21, 2015 at 2:03 PM, Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
><br>
> > On Wed, Jan 21, 2015 at 11:19:14AM +0530, Deepak Shetty wrote:<br>
> > > Good point and I agree to the below.<br>
> > > So all we need here is a way to differentiate trusted Vs non-trusted<br>
> > > clients and fail GETSPEC if it comes from non-trusted client provided the<br>
> > > disable glusterfs protocol option has been set ?<br>
> ><br>
> > Not only that.<br>
> ><br>
> > I would expect that the brick processes only allow access when the<br>
> > trusted-*.vol file is used to connect. That .vol file (obtained through<br>
> > GlusterD) contains a user/passwd (both UUIDs). If the connecting client<br>
> > does not pass the user/passwd to the brick process on connect,<br>
> > connections should be denied.<br>
> ><br>
> > I must admit that I have never looked at how/when the client passes<br>
> > these credentials to the bricks.<br>
> ><br>
> > Niels<br>
> ><br>
> > ><br>
> > > On Wed, Jan 21, 2015 at 8:42 AM, Vijay Bellur <<a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a>><br>
> > wrote:<br>
> > ><br>
> > > > On 01/19/2015 06:22 PM, Deepak Shetty wrote:<br>
> > > ><br>
> > > >> Hi All,<br>
> > > >> I had opened this feature request sometime back<br>
> > > >> <a href="http://www.gluster.org/community/documentation/index" target="_blank">http://www.gluster.org/community/documentation/index</a>.<br>
> > > >> php/Features/turn-off-glusterfs-proto-access<br>
> > > >><br>
> > > >> I wanted to know what would be the right way to implement this ?<br>
> > > >><br>
> > > >> The goal here is to have a volume set option to turn off<br>
> > glusterfs/fuse<br>
> > > >> protocol access<br>
> > > >> just like how we have it today for NFS ( volume set nfs.export-volumes<br>
> > > >> off)<br>
> > > >><br>
> > > >> 1) Does GETSPEC allow passing the protocol being requested at mount,<br>
> > so<br>
> > > >> that glusterd can return success/failure and mount.gluster can error<br>
> > > >> accoridngly ?<br>
> > > >><br>
> > > >> 2) Another way is to introduce another handshake after GETSPEC is<br>
> > > >> successfull, where client can request permission to mount using the<br>
> > said<br>
> > > >> protocol and glusterd returns success/failure based on the volume set<br>
> > > >> option being set or unset ?<br>
> > > >><br>
> > > >> Thoughts ?<br>
> > > >><br>
> > > ><br>
> > > > I think unconditionally disabling glusterfs protocol for trusted<br>
> > clients<br>
> > > > (clients local to the storage pool) also would not be ideal. An<br>
> > > > administrator might still want to access volumes through a trusted<br>
> > > > glusterfs client for maintenance, repair activities. Geo-replication,<br>
> > quota<br>
> > > > etc. do rely on the ability to access volumes from the trusted storage<br>
> > pool<br>
> > > > through the native glusterfs protocol for proper functioning.<br>
> > > ><br>
> > > > Given this, we could implement this feature by serving volfiles to only<br>
> > > > trusted clients in glusterd and fail requests from everywhere else if<br>
> > an<br>
> > > > option to disable glusterfs protocol has been set. This way all<br>
> > services<br>
> > > > accessing volumes locally from the trusted storage pool will continue<br>
> > to<br>
> > > > function without any problems.<br>
> > > ><br>
> > > > HTH,<br>
> > > > Vijay<br>
> > > ><br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > Gluster-devel mailing list<br>
> > > <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> > > <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
> ><br>
> ><br>
</div></div><br>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br></blockquote></div><br></div></div>