[quote=“Patrick, post:13, topic:533”][quote]What about the following?
- create a configuration file.
- create a hash file (sha1) of the configuration file (installed along the configuration file).
- each time CPFP gets a request, it runs the hash function of the configuration file and compares it to the hash file content.[/quote]
It would be best to go the standard way. The daemon load its config once started. To obtain new settings, either restart the daemon or send signal sighup (service reload).[/quote]
Yes, comparing the hash on every request is useless. Modified steps:
- create a configuration file.
- create a hash file (sha1) of the configuration file (installed along the configuration file).
- when CPFP is started, it runs the hash function of the configuration file and compares it to the hash file content.
Configuration GUI should be an optional bonus. Not the default way. Also please keep CLI users in mind.
If we want to compute the hash after the changes and save the string in a file, I do not see another way. There could be a warning message on top of it (generic_gui_message), in the style “Modify this file only if you know what you are doing. Do you really want to proceed?”.
[quote]Any user change creates a new hash file.[/quote]
That's only work in ~/. And in this case in /root somewhere. (Reminds me to change to obey xdg data dir standard some day.) Otherwise a file in /etc/ that changes would cause an interactive dpkg conflict resolution dialog each time there is an upgrade.
I overlooked that (a daemon should not have root privileges). The files could be in “$HOME/.config/cftp/”.
.d config folders are great for usability, I think. When disto's push an upgrade, user won't get an interactive dpkg conflict resolution dialog. And users can extend the config however they wish. Derivatives can add their configs on top without patching. Or is there any issue in python parsing them?
I do agree on the usability of the .d folders. Yes, the problem is parsing.
What you are doing in bash
if [ -d /etc/controlportfilt.d ]; then
for i in /etc/controlportfilt.d/*; do
if [ -f "$i" ]; then
~~~~
bash -n "$i"
source "$i"
fi
is very neat (although I do not fully understand the magic). It would be a whole different game to parse the controlportfilt.d directory in Python and make out what the real configuration is.
The configuration file I am working with:
[CONFIGURATION]
CONTROL_PORT_FILTER_LIMIT_GETINFO_NET_LISTENERS_SOCKS = True
CONTROL_PORT_FILTER_LIMIT_STRING_LENGTH = True
CONTROL_PORT_FILTER_EXCESSIVE_STRING_LENGTH = 128
[WHITE_LIST]
1 = GETINFO net/listeners/socks
2 = SIGNAL NEWNYM
3 = GETINFO status/bootstrap-phase
4 = GETINFO status/circuit-established
It is parsed in a few lines with Python configparser.
By the way, my repositories are visible. https://github.com/troubadoour/control-port-filter-python
