Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1246275

Summary:	POSIX ACLs as used by a FUSE mount can not use more than 32 groups
Product:	[Community] GlusterFS	Reporter:	Niels de Vos <ndevos>
Component:	fuse	Assignee:	Niels de Vos <ndevos>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	mainline	CC:	bugs, gluster-bugs
Target Milestone:	---	Keywords:	Reopened, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.8rc2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1246397 1252072 1275721 (view as bug list)		Environment:
Last Closed:	2016-06-16 13:26:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1246397, 1252072, 1275721

Description Niels de Vos 2015-07-23 21:19:07 UTC

Description of problem:
When enabling support for POSIX ACLs on a FUSE mount with the "-o acl" mount option, permission checks only use the first 32 groups of a user. If permissions of a directory/file are permitted by groups further in the group-list, the permissions are not applied. The group-list of the user is truncated to the fist 32 groups.

Version-Release number of selected component (if applicable):
mainline

How reproducible:
100%

Steps to Reproduce:
1. mount a volume with "-o acl"
2. create a lot of groups (33 or more)
3. create a user that belongs to a lot of groups
4. create a directory on the volume
5. add a POSIX ACL to the new directory, allow writes for the directory to the 
   last group the user belongs to (setfacl -m g:123456:rwx /path/new/dir)
6. create a new file in the director as the user

Actual results:
"Permission denied"

Expected results:
The user should be allowed to create the file, the user is member of the group with write access.

Additional info:
If the number of groups the user belongs to is higher than ~93, the volume option server.manage-gids needs to be enabled too.

Comment 1 Anand Avati 2015-07-23 22:14:49 UTC

REVIEW: http://review.gluster.org/11732 (fuse: add "resolve-gids" mount option to overcome 32-groups limit) posted (#2) for review on master by Niels de Vos (ndevos)

Comment 2 Anand Avati 2015-07-29 14:36:59 UTC

REVIEW: http://review.gluster.org/11732 (fuse: add "resolve-gids" mount option to overcome 32-groups limit) posted (#3) for review on master by Niels de Vos (ndevos)

Comment 3 Anand Avati 2015-08-05 11:53:26 UTC

COMMIT: http://review.gluster.org/11732 committed in master by Kaleb KEITHLEY (kkeithle) 
------
commit 64a5bf3749c67fcc00773a2716d0c7b61b0b4417
Author: Niels de Vos <ndevos>
Date:   Tue Jul 21 18:50:12 2015 +0200

    fuse: add "resolve-gids" mount option to overcome 32-groups limit
    
    Add a --resolve-gids commandline option to the glusterfs binary. This
    option gets set when executing "mount -t glusterfs -o resolve-gids ...".
    
    This option is most useful in combination with the "acl" mount option.
    POSIX ACL permission checking is done on the FUSE-client side to improve
    performance (in addition to the checking on the bricks).
    
    The fuse-bridge reads /proc/$PID/status by default, and this file
    contains maximum 32 groups. Any local (client-side) permission checking
    that requires more than the first 32 groups will fail.
    
    By enabling the "resolve-gids" option, the fuse-bridge will call
    getgrouplist() to retrieve all the groups from the user accessing the
    mountpoint. This is comparable to how "nfs.server-aux-gids" works.
    
    Note that when a user belongs to more than ~93 groups, the volume option
    server.manage-gids needs to be enabled too. Without this option, the
    RPC-layer will need to reduce the number of groups to make them fit in
    the RPC-header.
    
    Change-Id: I7ede90d0e41bcf55755cced5747fa0fb1699edb2
    BUG: 1246275
    Signed-off-by: Niels de Vos <ndevos>
    Reviewed-on: http://review.gluster.org/11732
    Tested-by: NetBSD Build System <jenkins.org>
    Reviewed-by: Ravishankar N <ravishankar>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: jiffin tony Thottan <jthottan>
    Reviewed-by: Kaleb KEITHLEY <kkeithle>

Comment 4 Nagaprasad Sathyanarayana 2015-10-25 15:20:27 UTC

Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.

Comment 5 Niels de Vos 2016-06-16 13:26:51 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report.

glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user