<div dir="ltr"><div>I didn't understand how the brick process point is relevant here ? Can you elaborate pls ?<br></div>If we are failing the GETSPEC itself there shouldn't be any question of client connecting to the brick process, no ?<br><br>I don't have much insights into the code but I am just thinking logically and saying the above<br><br>thanx,<br>deepak<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 2:03 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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>
</span>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>
<div><div class="h5"><br>
><br>
> On Wed, Jan 21, 2015 at 8:42 AM, Vijay Bellur <<a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a>> 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 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, 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 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 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, quota<br>
> > etc. do rely on the ability to access volumes from the trusted storage 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 an<br>
> > option to disable glusterfs protocol has been set. This way all services<br>
> > accessing volumes locally from the trusted storage pool will continue to<br>
> > function without any problems.<br>
> ><br>
> > HTH,<br>
> > Vijay<br>
> ><br>
> ><br>
<br>
</div></div>> _______________________________________________<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>