Bug 6035 - Possible race between fcntl F_SETLKW and alarm delivery in passdb/pdb_smbpasswd.c
Possible race between fcntl F_SETLKW and alarm delivery in passdb/pdb_smbpass...
Product: Samba 3.2
Classification: Unclassified
Component: File services
Other Linux
: P3 normal
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2009-01-14 14:50 UTC by Richard Sharpe
Modified: 2009-01-14 15:43 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Richard Sharpe 2009-01-14 14:50:37 UTC
This seems to be another example of the race I found a couple of days ago, although it looks like it has very low probability of hitting.

In passdb/pdb_smbpasswd.c:do_file_lock we see:

static bool do_file_lock(int fd, int waitsecs, int type)
        SMB_STRUCT_FLOCK lock;
        int             ret;
        void (*oldsig_handler)(int);

        gotalarm = 0;
        oldsig_handler = CatchSignal(SIGALRM, SIGNAL_CAST gotalarm_sig);

        lock.l_type = type;
        lock.l_whence = SEEK_SET;
        lock.l_start = 0;
        lock.l_len = 1;
        lock.l_pid = 0;

        /* Note we must *NOT* use sys_fcntl here ! JRA */
        ret = fcntl(fd, SMB_F_SETLKW, &lock);
        CatchSignal(SIGALRM, SIGNAL_CAST oldsig_handler);

        if (gotalarm) {
                DEBUG(0, ("do_file_lock: failed to %s file.\n",
                        type == F_UNLCK ? "unlock" : "lock"));
                return False;

        return (ret == 0);

The lock can be granted but if the timeout occurs before we are scheduled, we have the lock but think we don't.

This is in at least 3.2.0 and 3.0.21.

Solution seems to be to change:

-        if (gotalarm) {


+        if (gotalarm && (ret != 0)) {
Comment 1 Jeremy Allison 2009-01-14 15:43:17 UTC
Fixed in all branches - thanks !