-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[Windows] Dynamic Security Plugin stores changes in dynsec.json.new
instead of dynsec.json
(affected: >= 2.0.16).
#2967
Comments
I had the same issue and have confirmed that dynsec is working in V2.0.10 but fails in 2.0.18. For me, under 2.0.18 on Windows 10, I was unable to start the service if plugin_opt_config_file was defined and pointing at a "mosquitto_ctrl dynsec init" file. If it wasn't then the service started but log all has a warning that no config file was specified so the feature wouldn't do anything Also, in mosquitto.conf there is no entry or documentation comments for the plugin_opt_config_file setting. |
I don't know. When I looked at older binaries I noticed something. The installer file size changed significantly at two spots: 2.0.9a/2.0.11 and 2.0.16. Version 2.0.10 was the last one to maintain a small filesize (about 1.6MB), and afterwards (somehow also 2.0.9a) the installer grew nearly tenfold to about 14MB (with 2.0.13-14 being 16MB). Since 2.0.16 the filesize grew even further to about 26MB. I wonder if the changes in size during these spots were due to compiler changes. There's a portability issue with Probably older compilers handled the behavior in a portable way so it worked as desired for both Windows and Linux in this case (replacing the target file), but newer ones honored the intended behaviors for |
A bump on this as I did tests on different versions. This is on a same system with Win10 22H2. 2.0.15: LGTM. So the issue was not about Windows but the compiler/runtime changes happened during the period. I suppose if someone compiles 2.0.18 with the environment used to compile 2.0.15 the issue would be fixed without changing a single line of related code.
Considering the breaking change ( I've tried setting up a build environment for mosquitto but am so far unsuccessful. For now I'll be downgrading the affected system's mosquitto (which is 2.0.18) to 2.0.15 to work the issue around. |
ChangeLog.txt at ln 52 calls out a fix committed for 2.16 to address a race condition associated with mosquitto_ctrl init ... here's what changed. The code invokes mosquitto_fopen() in the WIN32 conditional block which does the .new create and rename around ln 615 in plugins/dynamic-security/plugin.c |
Does this affect only But the reality is, all operations that involve modifying |
dynsec.json.new
instead of dynsec.json
.dynsec.json.new
instead of dynsec.json
(affected: >= 2.0.16).
dynsec.json.new
instead of dynsec.json
(affected: >= 2.0.16).dynsec.json.new
instead of dynsec.json
(affected: >= 2.0.16).
I encountered it in mosquitto_ctrl and not sure what else may be involved. I'm a SQL geek- using a flat file this way seems like a strategy to avoid locks on the readers but finding/fixing the underlying issue is beyond me. |
Looks like the code changed a lot during the period... I was kinda confused... although the line causing the error in the current version is still apparent. I think the issue might be corrected if you |
The main reason for usage of rename is to ensure the existence of a valid dynsec config file under all circumstance (as far as this is possble from a pure application development). The posix compliant rename by definition guarantees the existing new file will be untouched, if anything in the rename goes wrong. |
@NorbertHeusser the portable behaviour seems a much more obvious solution for any compiler or os
|
OS: Windows 10 22H2
Mosquitto Version: 2.0.18
Additional notes:
Program Files
folder. I installed it to folder on a separate partition.SYSTEM
does have permissions to Mosquitto's installation folder and files inside it.On my system, when I made changes using
mosquitto_ctrl
, changes are not directly applied todynsec.json
. Instead, adynsec.json.new
file is created and all changes are stored there while originaldynsec.json
remain unchanged.This leads to a similar problem as #2938, as changes will be reverted on restart. Additionally, as I started Mosquitto as a service,
dynsec.json.new
would be created and owned bySYSTEM
which means my own user cannot read nor modify it unless I added necessary permissions.Further looking at the source code I found out it's storing the changes this way:
.new
file to store the changes..new
file to the original file.Since there would be an error message should the rename fail I enabled error/warning logs and after trying to make a change, I immediately got the following line in the log file.
I wonder if something in Win10 is getting in the way. On the other hand, I've another Windows system on which everything is working correctly (changes are correctly applied to the original file):
OS: Windows Server 2008 R2
Mosquitto Version: 2.0.10
Additional notes:
Program Files
.Administrator
account thus there's no UAC or anything.The text was updated successfully, but these errors were encountered: