Giters

opencog / cogutil

Very low-level C++ programming utilities used by several components

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hardwired DEFAULT_MODULE_PATHS

ngeiswei opened this issue · comments

commented

The list of paths to look for modules is entirely hardwired in

<COGUTILS_ROOT>/opencog/util/files.cc

Both the atomspace and opencog repos rely on it (which is why it is in cogutils) but it prevents from running the cogserver from certain places like

<OPENCOG_ROOT>/scripts

which contains run_cogserver.sh, thus failing to run the cogserver..

I guess there are 2 ways to properly deal with that

  1. have it look for a certain environment variable like OPENCOG_MODULE_PATHS
  2. add a config variable MODULES_PATH in opencog*.conf

meanwhile I've added ../build in the list of hardwired default module paths which I suppose should accommodate 90% of the users wanting to run the cogserver from that script.

commented

Hi Nil,

Note that the coserver can also be started from guile:

(use-modules (opencog cogserver))
(start-cogserver "optional config file name")
(stop-cogserver)

Half of the hard-coded paths are OK, the other half are just plain wrong. The OK hard-coded paths are the ones that point at the install directories. The bad hard-coded paths are all the relative paths. These should be replaced by an env var.

Relative paths, such as "build", are extremely evil.

The problem with the relative paths is that they cause huge amountsw of trouble, and waste huge amounts of debugging time: people check in code that depends on the relative paths, and that code works for them, but not for other people, and then we get these bug reports that "opencog doesn't work" and its a never-ending collision course of bad file paths. The more relative file paths that we use, the harder it is to debug things, the harder it is to spot the errors. I've wasted far too much time wrestling with file-paths in opencog, the whole concept is bad. Yet, the bug only bits infrequently, and fixing it is hard, so its low priority ...

I'm guessing that perhaps having the ENV var is the right fix....

commented

Good, I actually did remove the build hardwired paths and added a env variable instance OPENCOG_MODULE_PATHS.

commented

@linas do you consider the solution sufficiently adequate and the issue should be closed?

commented

Well, Config.cc still lists a bunch of relative search paths in DEFAULT_CONFIG_PATHS[] -- for example,

    "./",
    "../",
    "../../",
    "../../../",
    "../../../../",
    "./lib/",
    "../lib/",
    "../../lib/",
    "../../../lib/",

In the modern theory of computer security, this is a security hole, since an attacker could install a config file in some unsuspecting place (e.g. in the /tmp directory) and then opencog might find it (if running the cogserver in the /tmp directory), and use that evil config file to do ... something.

Given that this seems very unlikely, I think we can just leave this be, for now. Given that I seem to read about security breaches every day on slashdot, anything that allows a security breach to occur is just asking to get into the news.