[Lock] fix lock file permissions #27903
Merged
Conversation
This file contains hidden or 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
nicolas-grekas
approved these changes
Jul 9, 2018
xabbuh
approved these changes
Jul 9, 2018
| @@ -81,7 +81,7 @@ private function lock(Key $key, $blocking) | |||
| set_error_handler(function ($type, $msg) use (&$error) { $error = $msg; }); | |||
| if (!$handle = fopen($fileName, 'r+') ?: fopen($fileName, 'r')) { | |||
| if ($handle = fopen($fileName, 'x')) { | |||
| chmod($fileName, 0444); | |||
| chmod($fileName, 0666); | |||
There was a problem hiding this comment.
True, that should suffice of course.
There was a problem hiding this comment.
I don't think so as that would prohibit locks across different users, wouldn't it?
There was a problem hiding this comment.
@xabbuh good point
@nicolas-grekas what do you think? Should we change it back to 0666?
d4b4776 to
23481a1
Compare
|
Thank you @fritzmg. |
nicolas-grekas
added a commit
that referenced
this pull request
Jul 9, 2018
This PR was squashed before being merged into the 3.4 branch (closes #27903). Discussion ---------- [Lock] fix lock file permissions | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | see discussion below | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - See [this comment](#27668 (comment)). Since we are using `r+` now to fix an issue on Solaris, we also need to change the file permissions when the lock file is created for the first time. Otherwise ```php fopen($fileName, 'r+') ``` will fail due to the file permissions and while ```php fopen($fileName, 'r') ``` will work, the subsequent locking will again fail on Solaris. Changing the file permissions to `0666` fixes this issue. __However__ any lock file that was generated _prior_ to this change will still cause issues and would need to be manually deleted. Usually the default `sys_get_temp_dir()` location is used for the lock files and _usually_ these files are purged periodically, so it probably won't matter that much. But it still might cause some confusion since it will not be transparent, why the file lock failed on Solaris systems. Commits ------- 23481a1 [Lock] fix lock file permissions
nicolas-grekas
added a commit
that referenced
this pull request
Jul 9, 2018
This PR was squashed before being merged into the 2.8 branch (closes #27904). Discussion ---------- [Filesystem] fix lock file permissions | Q | A | ------------- | --- | Branch? | 2.8 | Bug fix? | yes | New feature? | no | BC breaks? | see linked discussion | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - See #27903 Commits ------- 7a68fea [Filesystem] fix lock file permissions
|
Just so that the discussion does not get lost: @nicolas-grekas I think we should use |
|
I fixed it to 0666 directly in the branch. |
This was referenced Jul 23, 2018
Merged
Merged
Merged
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.
See this comment. Since we are using
r+now to fix an issue on Solaris, we also need to change the file permissions when the lock file is created for the first time. Otherwisewill fail due to the file permissions and while
will work, the subsequent locking will again fail on Solaris.
Changing the file permissions to
0666fixes this issue. However any lock file that was generated prior to this change will still cause issues and would need to be manually deleted. Usually the defaultsys_get_temp_dir()location is used for the lock files and usually these files are purged periodically, so it probably won't matter that much. But it still might cause some confusion since it will not be transparent, why the file lock failed on Solaris systems.