[Gluster-devel] Ability to turn off 'glusterfs' protocol

Niels de Vos ndevos at redhat.com
Wed Jan 21 08:33:03 UTC 2015


On Wed, Jan 21, 2015 at 11:19:14AM +0530, Deepak Shetty wrote:
> Good point and I agree to the below.
> So all we need here is a way to differentiate trusted Vs non-trusted
> clients and fail GETSPEC if it comes from non-trusted client provided the
> disable glusterfs protocol option has been set ?

Not only that.

I would expect that the brick processes only allow access when the
trusted-*.vol file is used to connect. That .vol file (obtained through
GlusterD) contains a user/passwd (both UUIDs). If the connecting client
does not pass the user/passwd to the brick process on connect,
connections should be denied.

I must admit that I have never looked at how/when the client passes
these credentials to the bricks.

Niels

> 
> On Wed, Jan 21, 2015 at 8:42 AM, Vijay Bellur <vbellur at redhat.com> wrote:
> 
> > On 01/19/2015 06:22 PM, Deepak Shetty wrote:
> >
> >> Hi All,
> >>    I had opened this feature request sometime back
> >> http://www.gluster.org/community/documentation/index.
> >> php/Features/turn-off-glusterfs-proto-access
> >>
> >> I wanted to know what would be the right way to implement this ?
> >>
> >> The goal here is to have a volume set option to turn off glusterfs/fuse
> >> protocol access
> >> just like how we have it today for NFS ( volume set nfs.export-volumes
> >> off)
> >>
> >> 1) Does GETSPEC allow passing the protocol being requested at mount, so
> >> that glusterd can return success/failure and mount.gluster can error
> >> accoridngly ?
> >>
> >> 2) Another way is to introduce another handshake after GETSPEC is
> >> successfull, where client can request permission to mount using the said
> >> protocol and glusterd returns success/failure based on the volume set
> >> option being set or unset ?
> >>
> >> Thoughts ?
> >>
> >
> > I think unconditionally disabling glusterfs protocol for trusted clients
> > (clients local to the storage pool) also would not be ideal. An
> > administrator might still want to access volumes through a trusted
> > glusterfs client for maintenance, repair activities. Geo-replication, quota
> > etc. do rely on the ability to access volumes from the trusted storage pool
> > through the native glusterfs protocol for proper functioning.
> >
> > Given this, we could implement this feature by serving volfiles to only
> > trusted clients in glusterd and fail requests from everywhere else if an
> > option to disable glusterfs protocol has been set. This way all services
> > accessing volumes locally from the trusted storage pool will continue to
> > function without any problems.
> >
> > HTH,
> > Vijay
> >
> >

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150121/118cb487/attachment.sig>


More information about the Gluster-devel mailing list