RackSec / desdemona

Data-backed security operations
Eclipse Public License 1.0
2 stars 7 forks source link

Multi-arity features without literals #106

Closed lvh closed 8 years ago

lvh commented 8 years ago

Currently, the query language knows how to turn single feature equality into a logic program, e..g: (= (:ip x) "10.0.0.1") into (clojure.core.logic/featurec x {:ip "10.0.0.1"}). It should also know how to turn multi-arity equality into a featurec clause, which requires introducing a new logic variable. For example, it should turn (= (:ip x) (:ip y) (:ip z)) into:

(fresh [s#]
  (clojure.core.logic/featurec x {:ip s#})
  (clojure.core.logic/featurec y {:ip s#})
  (clojure.core.logic/featurec z {:ip s#}))

This is different from (= (:ip x) (:ip y) "10.0.0.1") because that includes a literal, so you can just implement it as the conjunction of:

(clojure.core.logic/featurec x {:ip "10.0.0.1"})
(clojure.core.logic/featurec y {:ip "10.0.0.1"})

Once infix querying is a thing (see #99), there should also be an infix version of this, i.e. turning ip(x) = ip(y) = ip(z) into (= (:ip x) (:ip y) (:ip z))

lvh commented 8 years ago

Although the two examples above are different, it is still possible to implement the version with a literal by introducing fresh; you just also need a unification clause. That may be easier to implement. As long as there are tests for both cases, that seems like an implementation detail...

lvh commented 8 years ago

If the toplevel logic query is no longer the only place we're introducing new logic variables, the find-free-vars logic that finds new logic variables that need introducing needs to be amended to be aware of that fact.

lvh commented 8 years ago

Hm. Instead; I'm going to implement this in the dsl -> logic compiler; since that will always know which vars are free and which ones aren't.

lvh commented 8 years ago

111 implements free variable marking correctly; so we don't have to worry about that part anymore. I guess that means I'll be implementing this next.