If FTL is being invoked in an unusual way, it can happen that the database is created as root and later re-owned to a low-privilege user. Since the default database mode is now WAL, we have additional -shm and -wal files which need to be re-owned as well or the database becomes read-only.
This permission issue "auto-fixes" on the next FTL restart and everything will be fine thereafter. Nonetheless, this PR ensures the permissions are already correct during the initial start and not only after the first restart.
Related issue or feature (if applicable): See linked Discourse thread below.
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
I have commented my proposed changes within the code.
I am willing to help maintain this change if there are issues with it later.
What does this implement/fix?
If FTL is being invoked in an unusual way, it can happen that the database is created as
root
and later re-owned to a low-privilege user. Since the default database mode is now WAL, we have additional-shm
and-wal
files which need to be re-owned as well or the database becomes read-only.This permission issue "auto-fixes" on the next FTL restart and everything will be fine thereafter. Nonetheless, this PR ensures the permissions are already correct during the initial start and not only after the first restart.
Related issue or feature (if applicable): See linked Discourse thread below.
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
git rebase
)Checklist:
developmental
branch.