Race condition in mythshutdown

[anonymous]

It looks like there may be a race condition in mythshutdown because the fetch and the update for the increment and decrement are done as as two different statements instead of a single atomic operation or being wrapped in a transaction to ensure consistency. The window is relatively narrow but since there are multiple system calls involved rescheduling is very possible. The issue here is that you don't get reliable reversability with multiple callers as was clearly intended. It's possible to have a sequence of --lock or --unlock operations leave the system in either state because they could be working on stale data

For example consider the following interleaved sequence:

Script A runs "mythshutdown -l" mythshutdown A fetches 0 Script B runs "mythshutdown -l" mythshutdown B also fetches 0 mythshutdown A stores 1 mythshutdown B stores 1

The correct value should have been 2, and because it's not, the first script that runs "mythshutdown -u" will unlock for both and leave the other caller unprotected. The same type of thing can end up with interleaved unlocks leaving the system locked when it should be unlocked.

[paulh]

(In [17342]) Fix a possible problem with mythshutdown --lock/--unlock.

The lock/unlock commands can be nested so if lock is called twice unlock would have to also be called twice to unlock shutdown. Each lock/unlock requires 2 db queries one to get the setting and one to save it back again. The problem is if two instances of mythshutdown is running the reads and writes could overlap each other resulting in the setting getting out of sequence.

This fixes the problem by using only one query to update the setting and also locks the table making it impossible for two mythshutdown processes to update the lock setting at the same time.

Refs #5269.

[paulh]

(In [17343]) Merge r17342 from trunk.

Fix a possible problem with mythshutdown --lock/--unlock.

The lock/unlock commands can be nested so if lock is called twice unlock would have to also be called twice to unlock shutdown. Each lock/unlock requires 2 db queries one to get the setting and one to save it back again. The problem is if two instances of mythshutdown is running the reads and writes could overlap each other resulting in the setting getting out of sequence.

This fixes the problem by using only one query to update the setting and also locks the table making it impossible for two mythshutdown processes to update the lock setting at the same time.

Fixes #5269.