XQuery advise

I've been thinking about the following situation all day,
and I figured 
one of you who has more XQuery experience than I can offer a
solution.

I'd like to accept untrusted queries with the stipulation
that certain 
subtrees not be visible. That is, I'd like to mark an
element with, say, 
the attribute "security=private" and then have
none of its decedents 
show up in  response to queries.

Since the query will pass through my hands before being
submitted to 
dbxml it seems like I should be able to somehow either
sanitize the 
input set or include a where statement, but then it also
seems like the 
query could be written in such a way as to defeat this.
Sanitizing the 
query itself, ensuring that has the proper filters, seems
just as tricky.

Perhaps a secure namespace?

Well, thanks for any suggestions.

~Chris


------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribesleepycat.com

Hi Chris,

Accepting untrusted (arbitrary) queries is always a bad
thing to do. 
There are numerous ways to cause a denial of service attack
by having a 
query that never returns, for instance.

However if you go ahead with this approach, I would suggest
that you do 
not try to manipulate the query, which has a very complex
structure and 
semantics. It is probably much more simple to execute the
query and 
manipulate the returned results before passing them on to
the user - for 
instance, in your case searching for all the
"security='private'" 
attributes, and stripping those sub-trees from the results.

John

Chris Carlin wrote:
> I've been thinking about the following situation all
day, and I figured 
> one of you who has more XQuery experience than I can
offer a solution.
> 
> I'd like to accept untrusted queries with the
stipulation that certain 
> subtrees not be visible. That is, I'd like to mark an
element with, say, 
> the attribute "security=private" and then
have none of its decedents 
> show up in  response to queries.
> 
> Since the query will pass through my hands before being
submitted to 
> dbxml it seems like I should be able to somehow either
sanitize the 
> input set or include a where statement, but then it
also seems like the 
> query could be written in such a way as to defeat this.
Sanitizing the 
> query itself, ensuring that has the proper filters,
seems just as tricky.
> 
> Perhaps a secure namespace?
> 
> Well, thanks for any suggestions.
> 
> ~Chris
> 
> 
> ------------------------------------------
> To remove yourself from this list, send an
> email to xml-unsubscribesleepycat.com
> 


-- 
John Snelson, Berkeley DB XML Engineer
Sleepycat Software, Inc
http://www.sleepycat.com

Contracted to Sleepycat through Parthenon Computing Ltd
http://blog.parthcomp
.com/dbxml


------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribesleepycat.com

To be a little more clear, this is more a case of helping
end users 
protect themselves from themselves, ensuring that their
queries don't 
accidentally return information that's not supposed to be
let out.

In my mind stripping information from the result is not much
of an 
option because the query may return nodes from the private
subtrees 
without the markers identifying them as private.

Is there an easy way to strip these subtrees in the first
place?

~Chris

> Accepting untrusted (arbitrary) queries is always a bad
thing to do. 
> There are numerous ways to cause a denial of service
attack by having a 
> query that never returns, for instance.
> 
> However if you go ahead with this approach, I would
suggest that you do 
> not try to manipulate the query, which has a very
complex structure and 
> semantics. It is probably much more simple to execute
the query and 
> manipulate the returned results before passing them on
to the user - for 
> instance, in your case searching for all the
"security='private'" 
> attributes, and stripping those sub-trees from the
results.
> 
> John


------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribesleepycat.com

Chris Carlin wrote:
> To be a little more clear, this is more a case of
helping end users
> protect themselves from themselves, ensuring that their
queries don't
> accidentally return information that's not supposed to
be let out.
> 
> In my mind stripping information from the result is not
much of an
> option because the query may return nodes from the
private subtrees
> without the markers identifying them as private.
> 
> Is there an easy way to strip these subtrees in the
first place?

If you're only allowing queries to run on one collection
(at a time), you
could pass a pre-filtered nodeset to the query as a
variable, and (somehow)
requiring the query to only use that nodeset (kludgie:
s/(collection|doc)\(.*\)|doc/$root/).

-- Steve


------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribesleepycat.com