5 ms·
The main issue is to use configuration files residing somewhere in the filesystem. This looks like a global variable in a codebase (something we generally try t
by lewo 3y ago
The main issue is to use configuration files residing somewhere in the filesystem. This looks like a global variable in a codebase (something we generally try to avoid).
Instead, the configuration file should be explicitly provided as a command line argument. Systemd sandboxing can also be useful to ensure the program only uses the expected set of files.
For instance, on my NixOS machine, the Nginx configuration is not in `/etc/nginx` but explicitly provided and can then be known with ps:
$ ps aux | grep nginx
nginx: master process /nix/store/9iiqv6c3q8zlsqfp75vd2r7f1grwbxh7-nginx-1.24.0/bin/nginx -c /nix/store/9ffljwl3nlw4rkzbyhhirycb9hjv89lr-nginx.conf
- ris58h 3y agoIt's not a bad idea but it's not applicable to every piece of software. I don't think that passing a config file for every git command would be convenient.
- viraptor 3y agoYou can change the commandline string at runtime. You could inject a fake "-c correct/path" even if it's not there. (That's useful for other things too, like injecting the git revision of the app into the commandline)
- jamann 3y agoHow long does it take you to type out that path?
- em-bee 3y ago/nix/store/9ii<tab>nginx.conf
- Karellen 3y ago> This looks like a global variable in a codebase (something we generally try to avoid). Aren't they more like global constants than variables? Loaded at startup, and never change during that run of the program. (With the exception of only explicitly being re-read on SIGUSR1 for daemon-like programs.) And global consts, or #defines, or whatever, are things we generally don't try to avoid?