Bug 1193174 - flock does not observe group membership
Summary: flock does not observe group membership
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: GlusterFS
Classification: Community
Component: nfs
Version: mainline
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: hari gowtham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1211787 1369445 1369446
TreeView+ depends on / blocked
 
Reported: 2015-02-16 18:33 UTC by Chris Good
Modified: 2021-03-01 05:04 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1211787 1369445 (view as bug list)
Environment:
Last Closed: 2020-03-12 12:36:56 UTC
Regression: ---
Mount Type: nfs
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Chris Good 2015-02-16 18:33:15 UTC
Description of problem:

flock works correctly when the locking user either owns or has group ownership of the file however if fails with a ENOLCK if the lockfile is only accessible through non-primary group membership.

For instance:

[grapeshot@admin03]$ls -l locktest2
-rw-rw-r--  1 apache    apache       0 Feb 16 17:31 locktest.lock

The lockfile is owned by apache, the test user is a member of the apache group:

[grapeshot@admin03]$ id
uid=500(grapeshot) gid=500(grapeshot) groups=500(grapeshot),48(apache)

Confirming that we have write access:
[grapeshot@admin03]$ touch locktest.lock 
[grapeshot@admin03]$ 

Therefore flock against that file should succeed, the simple test case being:

[grapeshot@admin03]$ flock -e 200  200>locktest.lock 
flock: 200: No locks available


Version-Release number of selected component (if applicable): Gluster 3.6.2-1


How reproducible:

Always fails when FS is mounted using the gluster built-in NFS.  With the same FS mounted instead using gluster-fuse it always succeeds.



Steps to Reproduce:
1. 
2.
3.

Actual results:


Expected results:


Additional info:

Volume Name: homegrapeshot
Type: Replicate
Volume ID: ced82a52-ae78-4225-919d-700987163888
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: admin-db01:/data/glusterfs/homegrapeshot/brick1/brick
Brick2: admin-db02:/data/glusterfs/homegrapeshot/brick1/brick
Options Reconfigured:
cluster.lookup-unhashed: off


Looking on the gluster servers we see the following errors:

2015-02-16 18:20:58.676592] E [client-rpc-fops.c:449:client3_3_open_cbk] 0-homegrapeshot-client-0: remote operation failed: Permission denied. Path: /Lodestone/marktest2/locktest.lock (b9de87e6-b500-417a-a064-e8075dde7082)
[2015-02-16 18:20:58.676768] E [client-rpc-fops.c:449:client3_3_open_cbk] 0-homegrapeshot-client-1: remote operation failed: Permission denied. Path: /Lodestone/marktest2/locktest.lock (b9de87e6-b500-417a-a064-e8075dde7082)
[2015-02-16 18:20:58.676878] E [nlm4.c:1347:nlm4_lock_fd_resume] 0-nfs-NLM: Unable to resolve FH: (10.8.8.60:690) homegrapeshot : b9de87e6-b500-417a-a064-e8075dde7082
[2015-02-16 18:20:58.676909] E [nlm4.c:1370:nlm4_lock_fd_resume] 0-nfs-NLM: unable to call lk()

The group membership on the gluster servers matches the client machine definitions.

Comment 2 Yaniv Kaul 2019-04-28 05:21:29 UTC
Still relevant?

Comment 3 hari gowtham 2019-04-29 06:51:38 UTC
I'm adding Jiffin from NFS, he would be the better person to answer this.

@Jiffin, Please do the needful.

Comment 4 Worker Ant 2020-03-12 12:36:56 UTC
This bug is moved to https://github.com/gluster/glusterfs/issues/911, and will be tracked there from now on. Visit GitHub issues URL for further details


Note You need to log in before you can comment on or make changes to this bug.