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

[Deepak Shetty]

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

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 --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150122/31609a07/attachment.html>