This day was spent on getting our file access unified. On the way I found and fixed a bug with major security implications.
The code used fopen(), popen(), system() and other calls in random ways depedning on where it happened in the code. Some parts of the code did one kind of pattern substitution, other parts did another kind, while the rest did not even attempt to substitute patterns in the file name.
The new code does the same file name processing for every file pcb-rnd tries to open, remove, rename or execute.
Any time a file name is specified, it can contain three kind of substitution:
A new config node called rc.path.design has been added; this node contains the directory in which the currently edited board is loaded from or saved to. This node together with the $() substitution allows the user to configure library paths to contain $(rc.path.design)/fps/ which means the local footprint lib is fps/ next to the board file. This is different from ./fps because ./ refers to the directory from which pcb-rnd is executed, which is not necessarily the same as the directory that hosts the board.
Finally, if library search path starts with "?", it will not produce an error message if it is not found. This is useful for specifying optional libraries.
The "?" optional path can be extended to other search paths later.
Now that every file access goes through a wrapper called src/safe_fs.c, it will be possible to centrally check/validate/filter file system accesses. There will be a system based on a lihata config file (not part of the normal conf tree for security reasons) where regex based rules can be written to control what paths pcb-rnd will be willing to access.
This feature is important for the web based application (planned for next year) but is also an useful tool if the user wants to work around bugs or features of pcb-rnd; e.g. the user may be able to deny pcb-rnd to modify the user config or even redirect (rewrite) paths.