[Gluster-devel] rpc: solving issues with users that belong too many (> 93) groups

[Niels de Vos]

Hi all,

TL;DR:
  I'd appreciate it if someone can review http://review.gluster.org/7501


There is a well known limit for the number of groups (16) that NFS, or 
more specifically the RPC/AUTH_SYS header can transfer from client to 
server. Originally, Gluster suffered the same restriction, but by 
inventing it's own RPC/AUTH_GLUSTERFS_V2 header, this limit was 
overcome.

Unfortunately, it seems that there is a protocol specification that 
limits the size of the RPC/AUTH header to 400 bytes [1]. The maximum 
number of groups that RPC/AUTH_GLUSTERFS_V2 can carry is limited to 
93 (depending on the size of other attributes in the header) [2].

NFS servers have solved this by providing an option to resolve the 
groups on the NFS-server (using nss, ldap, nis, ..) and disregarding the  
groups from RPC/AUTH_SYS that the nfs-client sends.

* The Gluster/NFS server offers this as a volume option: 
  nfs.server-aux-gids
* The Linux kernel NFS server offers --manage-gids for rpc.mountd.

I'm proposing a similar option for the GlusterFS protocol. Internally 
Gluster can use up to 65535 groups, the limitation is completely 
contained in the RPC/AUTH_GLUSTERFS_V2 header. A new volume option 
called 'server.manage-gids' has been implemented and tested. This option 
causes the glusterfs-client to not send any auxiliary groups, and the 
brick processes will resolve the groups of the user themselves. This 
obviously, just like the NFS solution, requires that all storage servers 
can resolve the groups of any users (ldap, nis, ...).

More reviews for http://review.gluster.org/7501 are more than welcome.  
A little of background and previous related bug fix can be found in [2].

Many thanks,
Niels


[1] http://tools.ietf.org/html/rfc5531#section-8.2 see opaque_auth
[2] http://review.gluster.org/7202