drone115b / dirb Goto Github PK

Should path contexts be lists, instead of scalars, somehow accounting for soft links? Would be nice if soft links "just worked" -- translating between the soft link synonym and the dirb schema-expected path.

dirb queries seem to be restricted to directories (maybe intentionally as seen in lines in dirb.ds where os.path.isdir() checks are made).

It would be a nice feature if we could have this mechanism configurable, so we can possible have "File"Levels which encompass files and not directories.

Not sure if this is the same as issue #2

Might be nice to implement additional functions for path expressions:

  ["parameters-match", {'show':'dom*'}] # use fnmatch?
  ['bookmarks-above', [value,value]]
  ['bookmarks-below', [value,value]]
  ["attributes-match", {'show':'dom*'}] # a has-attributes operations may be ['attributes-match', {'key':'*'} ]  # ATTRIBUTES PREDICATES ONLY WORK IF THE ATTRIBUTE IS A STRICT KEY-VALUE PAIR!
  ['attributes-below', ['key','key']]

We should have a "system lock" where root can create (and own) a file of a given name
(how about "sys_lock" and dirb will not create directories underneath that ds.
Do we need a "read_lock" to prevent reads below a certain level? Does that mean
we need a "read_lock" and "write_lock" ??

Should PathTraversalContext also include bookmarks?

It is a worthwhile feature to have automated filename support. At particular levels, some filenames could be automatically generated on demand according to specifications in the template?

Should the lock on the dirb server be a multi-lock (exclusive, write, read) ?

Would be nice to support directory structures where a parameterized directory's key was a substring of the directory name. So, for example, a parameterized directory named "asset_redcar" might return a value of "redcar". The parent directory might contain many directories with the "asset_" prefix.

Should there be additional long-term logging to allow forensic debugging, for example, who created a particular directory?