-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG][DISCUSSION] file.manage_file
might cause race condition due to permission config
#65651
Comments
Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. |
I've taken a close look at the issue with the file.manage_file module and the potential race condition due to how permissions are handled. Here are my thoughts on the solutions you presented and a detailed suggestion based on our discussion: Thoughts on Proposed Solutions
Proposed Solution Suggested Changes
This approach avoids modifying |
Description
The
file.manage_file
module can cause unexpected problems due to the way it handles permissions. I am happy to provide a PR, but wanted first discuss which approach would make the most sense to the maintainers.The
file.manage_file
module currently works as such:The tmp file always has the
600
permissions, together with the current user + group.Race condition case
/etc/hosts
,/etc/nsswitch.conf
, or/etc/nscd.conf
.600
permissions.Downstream issue:
Discussion
This is an understandable issue--we are modifying a file that is currently in use, and we cannot guarantee correct file permissions while the module is still executing. However, in some cases (like managing DNS in a running environment), it is impractical to stop the service that uses the file.
A few solutions that come to my mind:
Solution 1
Possibly the least intrusive way to solve the issue is to ensure that the temporary file uses the final permissions. The advantage is that when the tmp file is copied to destination, it's immediately ready to be used.
I can imagine corner cases, like changing the permissions such that salt itself cannot write into the temp file. We could mitigate this by having an additional property, e.g.
atomic_permissions
, that'd turn off the behavior by default.Solution 2
We could alternatively modify the salt.utils.files.copyfile function to include permissions, and do a best-effort user/group/mode config within the function.
This would mitigate the issue by greatly reducing the window between file copying and file permission change. The issue would not be 100% solved though.
The disadvantage, in my mind, is that this would have to be a best-effort user/group/mode configuration because we probably wouldn't want to duplicate or pull in https://github.com/saltstack/salt/blob/master/salt/modules/file.py#L5069 into the utils module.
Do you have any preference for the approach to fix/mitigate the issue? Alternatively, is there another solution that I haven't considered?
The text was updated successfully, but these errors were encountered: