Fix device and spool file locking #33
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Refactor Heyu device and spool file locking code to follow recommendations found in "Secure Programming Cookbook for C and C++" book by John Viega and Matt Messier. While being at it, allow using only one of lock file formats, HDF UUCP (default) or binary, when reading form a lock file. Support for reading and also creating binary locks instead of the default HDP UCCP can be selected at compile time if needed. Reading PIDs with both methods while creating only the HDF UUCP lock files seems incompatible with systems and/or 3rd party applications which use binary format. For lock files to work correctly, all applications must use either the same format or both formats in parallel when both creating and checking lock files. Signed-off-by: Janusz Krzysztofik <[email protected]>
A patch supposed to fix locking introduced inconsistent use of an argument accepted by device_lock(), first interpreted as a lock file pathname, then as a name of device or resource protected by the lock. That inconsistency resulted in a pathname pointing to an unexistent file used when trying to confirm successful locking by reading back content of the lock file just created. Update device_lock() to accept device / resource name instead of lock file pathname as its argument and calculate lock file pathname itself, then update its user. Also, fix incorrect resource name used when trying to remove write lock file on error before exit. Signed-off-by: Janusz Krzysztofik <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor Heyu device and spool file locking code to follow recommendations
found in "Secure Programming Cookbook for C and C++" book by John Viega
and Matt Messier.
While being at it, allow using only one of lock file formats, HDF UUCP
(default) or binary, when reading form a lock file. Support for reading
and also creating binary locks instead of the default HDP UCCP can be
selected at compile time if needed. Reading PIDs with both methods while
creating only the HDF UUCP lock files seems incompatible with systems
and/or 3rd party applications which use binary format. For lock files to
work correctly, all applications must use either the same format or both
formats in parallel when both creating and checking lock files.
Signed-off-by: Janusz Krzysztofik [email protected]