Others
A key concept to support CTS queries with element level security is query rolesets. A query roleset is simply a list of roles. When indexing, MarkLogic Server takes query roleset information into consideration and essentially “partitions” indexes based on query rolesets. All queries (except for composite ones like and-query) will look into indexes for different query rolesets based on the caller’s role and logically “OR” the results. See Query Rolesets for more about query rolesets.
There are special rules for CTS queries, phrase breaks, field values, geo element pairs, auditing and term-queries when the elements involved are protected.
CTS queries - Positions are always calculated based on the original (full) document, prior to any concealing. This implies that the distances calculated based on indexes will be larger than what appears in the concealed document.
Phrase breaks - When indexing, any element that is protected is considered a phrase break. Consider this example:
<foo>1<bar>2 3</bar>4</foo>. If “bar” is protected by any protected path, then it is considered a phrase break regardless of whether a phrase through is defined on it. So, in the example, “2 3” is still a phrase, but “1 2” or “3 4” is not. “1 4” is not a phrase either.Fields - For an XML document, field values or field range values are sometimes calculated by concatenating elements included in the field. If those elements don’t have the same rolesets (permissions), concatenating can cause leaking of information. MarkLogic Server will treat this as a misconfiguration and log a warning. The query result on such a field is undefined.
Geo element pair with inconsistent permissions - Similar to the field case above, if permissions on the two elements (or JSON properties) of the geo pair are not consistent (or either of the two elements has different permissions from the parent node), MarkLogic Server will treat it as a misconfiguration and log a warning. The query result is undefined in this case.
Auditing -
For the “document-read” event, if the node involved has any element concealed, the string “concealed” will be reported in the event. Here is an example:
2016-10-18 15:45:29.886 event=document-read; type=concealed; uri=foo.json; database=Documents; success=true;
When a node or properties update built-in call is rejected due to the lack of element-level permissions, the “no-permission” event will be reported. This is very similar to how the event is used when such a call is rejected due to the lack of document-level permissions.
term-query - Element level security won’t prevent a “malicious” user from getting a term key through
xdmp:plan()from a different MarkLogic Server deployment, then passing that to acts:term-queryto find out information she is not supposed to see on the current MarkLogic Server deployment. The solution is to add a new execute privilege “term-query” to “protect”cts:term-query. For backward compatibility, this privilege will only be checked when element level security is in use (for example, when at least one protected path is configured).