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

[Kaushal M]

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.

~kaushal

On Fri, Jan 23, 2015 at 2:21 AM, Niels de Vos <ndevos at redhat.com> wrote:

> 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
> > >
> > >
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150123/fd4c3669/attachment.html>