Hi Terry, Terry Yapt wrote: > I have been reading blog and BQL "manual". It seems pretty cool.
Thanks :) > I have a question and perhaps a silly question. In advance I must to > say I don't know how the store is organized and what is the > security/privacity level we want/require to access it, but looking at > the easier example on blog, I have a question: > > What will be the result of this BQL ? > > |! nmap.type 9999| This would just turn into a where clause, WHERE so.type != 9999, ignoring the | characters. If your | characters were intentional, then it wouldn't parse - it looks like the start of WHERE (so.type != 9999) OR ( ... OR ...), but those last two terms either side of the OR are missing. The parser detects those failure modes and just won't accept it. I think the root of your question, though, is "Can I set up BQL statements which are potentially dangerous in some way?". I hope the answer to this is roughly, "no". In terms of the BQL queries themselves, the language is so simple and the parser so simple that it's really quite safe. You can't have more than fifty terms in the current implementation, so it's bounded in terms of memory size, and it's really robust in terms of not accepting things which aren't valid in terms of BQL before it even tries to turn things into SQL. Once you've got valid BQL, is it possible to turn this into unsafe SQL? Again, it's designed not to be like that. You can't inject random SQL statements: there are known operators, and everything else is basically just data, so injection attacks will be impossible as far as I'm concerned. It might be possible to write BQL which turns into a very hard to compute SQL query which effectively makes SQLite work very hard. This is something I'm going to explore when we're much closer to being finished: I'm not sure if it will happen, and if it does it might be difficult to guard against. However, anyone running BQL against the store has to be authenticated anyway, so the only outside denial of service possible is if we code queries into Bongo itself which have severe performance problems. This is definitely something that I'm going to be coding for, not because I think it's a security problem per se, but because I want to detect where our queries are going slowly (taking longer than a couple of seconds, really) and finding out how we can improve that. > PS: Do we have a document with the store organization explained ??? In terms of the internal design, at the moment not really because I'm in the process of redesigning bits. However, I am documenting things as I go along, and I will try to work on the documentation a bit more before I get any further! Thanks, Alex. _______________________________________________ Bongo-devel mailing list [email protected] https://mail.gna.org/listinfo/bongo-devel
