[Bro-Dev] script loading implementation

Jonathan Siwek jsiwek at ncsa.illinois.edu
Thu Jun 16 12:43:47 PDT 2011


> > 1) all paths branching off BROPATH that lead to the
> > script-being-loaded should be considered as loaded
> 
> I'm not sure I understand what you're saying here.

If I have a script: policy/A/B/script.bro

and a BROPATH containing: policy:policy/A

then when a script is loaded via "@load B/script", the scanner needs to consider both "B/script" and "A/B/script" as already loaded (they're the same file, but we need to know all possible subpaths of paths in BROPATH that can lead to the file).

Another way to do it could be to canonicalize inputs to the shortest subpath of a path in BROPATH that can load the script.

If you want a real example to play around with, try figuring out the right way to load "policy/protocols/conn/base.bro" as a command line argument to bro in the policy-scripts-new branch.  (pretend you don't know that the script actually gets loaded by default because of some crazy packet-filter -> notice -> conn dependencies)

Here's the order of attempts I made

fail:    `./src/bro protocols/conn/base.bro`
fail:    `./src/bro protocols/conn/base`
success: `./src/bro conn/base`

> > 2) inputs to @loads (and user arguments) without a .bro extension
> > should also consider the .bro input form as loaded (currently it
> > only does the reverse)
> 
> Does that gain much benefit?  Wouldn't the file with the same name as
> a directory already be inaccessible due to path ordering?

This doesn't have to do with scripts and directories having the same name.

This has to do with why this succeeds:

    `./src/bro conn/base`

while this fails:

    `./src/bro conn/base.bro`

> I've been thinking about this a bit some too and I've was considering
> removing the subpaths from the default BROPATH.  It would make it so
> that if you wanted to load the core http analysis, you'd have to
> load protocols/http.  I know that doesn't really address what you're
> talking about here, but it should help avoid any potential path
> problems in the default install.

Actually, I think that would address the first problem I'm talking about (not the second regarding .bro extension canonicalization).  But seems like something someone might try to do again the future only to run into the same problems I did.

- Jon


More information about the bro-dev mailing list