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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > http://www.gluster.org/mailman/listinfo/gluster-devel > >
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
