Local configuration should be parsed, not evaluated

[Peter TB Brett]

 affects geda
 security yes
 private no
 done

Currently, per-directory rc files are evaluated as Scheme scripts. This
is an arbitrary code execution security risk. For example, users (and
in particular *new* users) are likely to want to download and open
designs from elsewhere, and almost all designs include a 'gafrc' file to
set up per-project component libraries.

Instead of being evaluated, local configuration files should be parsed.
This way it would be much harder to craft malicious designs.

An example of a parsable configuration file format is the resource file
format used by PCB.

In addition, a tool should be developed for migrating existing designs'
rc files to the any configuration system.

[John P. Doty (jpd-noqsi)]

This isn't only a security problem. Tools that don't use libgeda still need to be able to read the configuration. Such tools may not be written in Scheme, and in any case won't contain the definitions from libgeda.

Another issue is that local configuration files need to override system and user configuration settings. Therefore, for clarity and discipline, the system and user configurations should also be parsed but not evaluated. And, of course, the tools mentioned above need to read these too.

[Krzysztof Kościuszkiewicz (k-kosciuszkiewicz)]

Does it make sense to change to another configuration file format?
Maybe configuration files can be evaluated in a sandbox environment - if supported by Guile.
Another way is to treat the files like a Scheme list, ie interpret them instead of evaluating.

[Peter TB Brett (peter-b)]

Sandboxes are always difficult, if not effectively impossible, to make completely airtight, as you must ensure that *any combination* of functions available within the sandbox cannot lead to a breakout. In any case, Guile does not have sandboxing support.

At the moment, I'm not particularly concerned about the actual on-disk format used. That's very much determined by the content we want to store in the configuration file, anyway.

I've started working on a spec for what the API should look like. You can keep track of my progress here:

http://repo.or.cz/w/geda-gaf/peter-b.git/blob/refs/heads/config-sys:/docs/specifications/config-api.txt

Or, if that URL gets mangled: http://goo.gl/Lcbna

Let me know if the approach seems insane.

[Peter Clifton (pcjc2)]

Sandbox -> Bad
Evaluating the file as an s-expr - OK.

[Krzysztof Kościuszkiewicz (k-kosciuszkiewicz)]

Spec looks ok - I guess you wanted it to map nicely to GKeyFile or similar "ini" file structure.
How about Scheme hooks? s-expr evaluation would be difficult here, and config file would accommodate this type of data.
Maybe a config value with list of extra Scheme files to load - it would have to be forbidden/ignored in the "per project" configuration context.

[Peter TB Brett (peter-b)]

On Thursday 13 January 2011 19:59:20 you wrote:
> Spec looks ok - I guess you wanted it to map nicely to GKeyFile or similar
> "ini" file structure. How about Scheme hooks? s-expr evaluation would be
> difficult here, and config file would accommodate this type of data. Maybe
> a config value with list of extra Scheme files to load - it would have to
> be forbidden/ignored in the "per project" configuration context.

That's correct; my current plan is to use GKeyFile as the storage layer. But
I'd quite like to hide the underlying implementation from the API user, so
that if it comes up towards 1.8.0 and we realise that GKeyFile doesn't cut the
mustard then we only have to change libgeda. ;-)

For per-project Scheme code, my current plan was to allow all config files to
specify plugins to load, but to only allow setting the plugin search path in
user and system config files. I.e. you should have to get the user to install
your nasty Scheme code in an approved plugins directory *and* get them to load
your dodgy gEDA files. Nothing in a config file should *ever* be evaluated.

Once the API spec is done we need to go through *all* the existing "things
people can do in rc files" and work out whether they can be migrated directly,
or whether other changes are needed to facilitate the change (for example,
component libraries, colour maps and print paper sizes all need to have their
underlying mechanisms looked at & possible altered). That'll give us a check
on whether the new config API can actually fulfil all of the roles that it
needs to fill, and, as a side benefit, will provide the information we need to
implement a migration tool to help users upgrade.

It's going to be pretty dull work, unfortunately, but I think it's important
to make sure that if we're going to rip out the existing configuration system
we replace it with something that's going to do the job and do it well!

[Peter TB Brett (peter-b)]

Just updated the API proposal (http://goo.gl/Lcbna) with some exciting new info on freezing and thawing of configuration events (suggested by Peter C), and a beautiful ASCII-art diagram of how configuration events propagate. Still left to do: actual API for registering configuration event handlers; details of handler calling convention; boring details of error codes.

Also, question for your consideration. Where should we search for system configuration?

- Should we just look in ${sysconfdir}?
- If so, should we only ever use the compile-time value, or should we support relocation?
- If we support relocation, how do we do it?
- Should we use XDG_CONFIG_DIRS?

P.S. sorry about the word-wrapping fail above -- Launchpad seems to disagree with the wrap column of my e-mails.

[Krzysztof Kościuszkiewicz (k-kosciuszkiewicz)]

I think relocation should be supported for the sake of portability with win32, where location of files is selectable during installation.
Maybe an environment variable will do? Not sure if win32 users would know the meaning XDG_CONFIG_DIRS.

[Peter TB Brett (peter-b)]

The API proposal is now completed, and ready for more detailed comments and suggestions.

http://goo.gl/Lcbna

The next step is a document detailing how existing configuration parameters would be translated over to the new system.