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
Attachment:
pgp18sK8VnU2Q.pgp
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
