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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxx
> http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
