Potential race conditions in FileSessions due to deletion of lock files

I’m submitting a …

• bug report
• feature request
• question about the decisions made in the repository

What is the current behavior? In the current implementation (using zc.lockfile) and removing the lockfile in lib/sessions.py it is possible that two processes/threads obtain a lock on the identical session lock file. This of course can lead to problems when one thread/process writes into a session file (but hasn’t finished) and another thread/process reads incomplete data from it (leading to unpickle errors).

The scenario works because of this: P1 opens file P1 locks file P2 opens file P1 unlocks file P1 removes file P2 locks file (creating a lock on the removed file) P3 opens file (creates a new lock file) P3 locks file (now both P2 and P3 hold a lock on the same file)

If the current behavior is a bug, please provide the steps to reproduce and if possible a screenshots and logs of the problem. If you can, show us your code.

import fcntl, os
flags = fcntl.LOCK_EX | fcntl.LOCK_NB
fp1 = open('x.lock', 'a+')  # first file handle and file descriptor for the lock file
os.remove('x.lock') 
fp2 = open('x.lock', 'a+')  # second file handle and descriptor for the lock file
lock1 = fcntl.flock(fp1.fileno(), flags)   # obtain lock in deleted file
lock2 = fcntl.flock(fp2.fileno(), flags)   # obtain 2nd lock on new file

The simple (but maybe not the desired solution) would be to not remove the lock file.

What is the expected behavior? The 2nd lock should fail

I went back to a very old Cherrypy Version (3.2.2), there the so called ‘naive’ lock file approach via fd = os.open(path, os.O_CREAT | os.O_WRONLY | os.O_EXCL) was used, this indeed is very reliable, I could not reproduce my session lock errors with that 😉

Please tell us about your environment:

• Cheroot version: 6.5.5
• CherryPy version: 18.1.1
• Python version: 3.6.3
• OS: Centos7
• Browser: all

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)

[jaraco]

To some extent, I wish this issue were addressed upstream in zc.lockfile. If there’s a race condition present when a lock file is deleted, and not deleting the file is the recommended approach, that should be documented upstream to prevent other consumers from making this mistake and formalizing the solution (don’t delete lock files or defer deletion).

If instead the zc.lockfile considers this issue an inherent design flaw and something that could be addressed in zc.lockfile itself, then I’d prefer that approach.

If someone would be willing to file the ticket upstream (mainly to describe the issue in a pure-zc.lockfile form), I’d be happy to shepherd it through.

[suheb]

Great, I’ll start working on this tonight.