Bug 186589 - Cannot set a read or write lock on a file that has "group execute" bit set in GFS 6.1
Cannot set a read or write lock on a file that has "group execute" bit set in...
Status: CLOSED NOTABUG
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ryan O'Hara
GFS Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-24 11:10 EST by Kyle Gonzales
Modified: 2010-01-11 22:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-11 12:12:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kyle Gonzales 2006-03-24 11:10:23 EST
Description of problem:

Cannot set a read or write lock on a file that has "group execute" bit set: e.g.
(see red)
     *  
       [tangzx2@mrtl4 temp]$ ls -ltr temp.txt
       -rw-rwS---  1 tangzx2 idev 347785 Jan 17 10:22 temp.txt

       Could not get read lock on temp.txt
       errno=37:No locks available

       If I remove the S bit from temp.txt, then both read lock and write lock
worked fine.

the way the locking was invoked:
     *  
       struct flock mylock;
       mylock.l_type=F_RDLCK;
       mylock.l_len=0;         /*lock entire file */
       mylock.l_whence=SEEK_SET;
       mylock.l_start=0;
       while (fcntl(fd,F_SETLK,&mylock) == -1)
       {
               if (errno!=EAGAIN)
               {
                       fprintf (stderr,"Could not get read lock on %s
errno=%d:",filename,errno);
                       perror ("");
                       exit(1);
               }
               printf ("%s locked, trying again\n",filename);
       }

GFS environment:
     * // from fstab
       /dev/home_vg/lvol0      /home                   gfs     defaults        0 0
        
       // version
       [tangzx2@mrtl4 sbin]$ ./gfs_quota -V
       gfs_quota 6.1.2 (built Jul 13 2005 16:42:11)
       Copyright (C) Red Hat, Inc.  2004-2005  All rights reserved.

Version-Release number of selected component (if applicable):
RHEL4/GFS6.1
Comment 1 Ryan O'Hara 2006-04-11 12:12:20 EDT
When the group execute bit is sgid (setgroupid) on a file, mandatory file
locking is invoked. From the fcntl man page:

--

Mandatory locking

(Non-POSIX.) The  above record locks may be either advisory or mandatory, and
are advisory by default. To make use of mandatory locks, mandatory locking must
be enabled (using the "-o mand" option to mount(8)) for the file system
containing the file to be locked and enabled on the file itself (by disabling
group execute permission on the file and enabling  the set-GID permission bit).

Advisory locks are not enforced and are useful only between cooperating
processes. Mandatory locks are enforced for all processes.

--

This file has the setgid bit set but *not* the group execute bit, which doesn't
make a whole lot of sense, which is why it was chosen to indicate that mandatory
locking occur. GFS does not support mandatory locking.

What is interesting here is that the fcntl man page seems to indicate and the
permission bits must be set (group execute off, setgid on) *and* the "-o mand"
option is use to mount the filesystem. The "-o mand" option was not set, so I am
not sure why mandatory locking was attempted.


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