Bug 6035 - Possible race between fcntl F_SETLKW and alarm delivery in passdb/pdb_smbpasswd.c
Summary: Possible race between fcntl F_SETLKW and alarm delivery in passdb/pdb_smbpass...
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
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 !