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

[Niels de Vos]

On Thu, Jan 22, 2015 at 08:40:30PM +0530, Deepak Shetty wrote:
> I didn't understand how the brick process point is relevant here ? Can you
> elaborate pls ?
> If we are failing the GETSPEC itself there shouldn't be any question of
> client connecting to the brick process, no ?
> 
> I don't have much insights into the code but I am just thinking logically
> and saying the above

Well, failing the GETSPEC will prevent the standard usage from
connecting to the bricks. But, in case the client uses a .vol file
directly, GETSPEC is not used (I assume, but could be wrong).

Because a .vol file can contain the 'trusted' credentials, I am of the
opinion that when 'disabling' the GlusterFS protocol, the bricks should
only accept connections with those trusted credentials.

That way self-heal and all can still do their work (they run inside the
Trusted Pool that receives the trusted credentials with GETSPEC).

Clients that still have an old .vol file will be denied access, because
those clients were not in the Trusted Pool and hence do not have the
trusted credentials.

Is is it a little clearer with this example? If not, let me know :)

Niels

> 
> thanx,
> deepak
> 
> 
> On Wed, Jan 21, 2015 at 2:03 PM, Niels de Vos <ndevos at redhat.com> wrote:
> 
> > 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/20150122/4db69b9e/attachment.sig>