$ tar xzf /.../greensql-fw-0.8.4.tar.gz
$ cd greensql-fw-0.8.4/
$ make
...
connection.hpp:29: error: field 'proxy_event' has incomplete type
connection.hpp:30: error: field 'client_event' has incomplete type
可以看出，在编译开始后，我们收到了几个错误，这是由于在Fedora 9上安装时，笔者并没有安装libevent-devel。在安装好libevent-devel后，又发现需要修改/usr/include/event.h，为编译事件代码，需要将sys/types.h包括进去。 vi /usr/include/event.h ... #include #include #include #include
在使用“make -k”命令时，有几个文件又出现了差错，这些文件调用了字符串函数，如“strcasecmp”，这是由于没有包括 string.h头文件所致。对读者来说，根据所使用的gcc的版本的不同，在编译GreenSQL时，可能会出现类似或不类似于下面的一些问 题： $ cd src $ vi mysql/mysql_con.cpp ... // License: GPL v2 (http://www.gnu.org/licenses/gpl.html) // #include
#include "mysql_con.hpp" ... $ vi config.hpp ... #ifndef GREEN_SQL_CONFIG_HPP #define
GREEN_SQL_CONFIG_HPP #include ... $ vi ../src/parser/expression.hpp ... #ifndef _SQL_EXPRESSION_HPP_
./setup_binary.sh done... # vi /etc/greensql/greensql.conf ... [database] dbhost=127.0.0.1 dbname=greendb
dbuser=greendb dbpass=greendbpass ... # chkconfig --add greensql service greensql does not support chkconfig #
/etc/init.d/greensql start
软件包的install.txt文件描述了手动安装方法，与脚本所使用的命令相同。使用脚本可能更好一些，因为这样可以提高安装速度， 而安装程序基本相同。安装指南推荐在/etc/greensql目录之前设置MySQL数据库，不过如果你这样做的话，有可能无法找到配置文件 ，所以你必须手动更改/etc/greensql/greensql.conf文件。你对greensql.conf作出的唯一主要更改是获取MySQL数据库参数。为测试需要，笔者创建了一个称为“test”的数据库，并允许用户“ben”自由访问，命令如下： # mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
mysql> GRANT ALL ON test.* TO ben@"%";
mysql> FLUSH PRIVILEGES;
默认情况下，GreenSQL运行在3305端口上，小于MySQL的默认端口（3306）。如果你使用mysql控制台客户端并连接到GreenSQL的3305 端口上，你将无法创建新表。如果你直接通过3306端口连接到MySQL,就可以创建新表。 $ mysql --verbose -h 127.0.0.1 -P 3305 test
mysql> create table foo ( id int );
--------------
create table foo ( id int )
--------------
Query OK, 0 rows affected (0.01 sec)
mysql> insert into foo values ( 55 );
--------------
insert into foo values ( 55 )
--------------
ERROR 1146 (42S02): Table 'test.foo' doesn't exist
$ mysql --verbose -h 127.0.0.1 -P 3306 test
Welcome to the MySQL monitor. Commands end with ; or \g.
mysql> create table foo ( id int );
--------------
create table foo ( id int )
--------------
Query OK, 0 rows affected (0.01 sec)
mysql> insert into foo values ( 55 );
--------------
insert into foo values ( 55 )
--------------
Query OK, 1 row affected (0.00 sec)
mysql> insert into foo values ( 131 );
--------------
insert into foo values ( 131 )
--------------
Query OK, 1 row affected (0.00 sec)
mysql> select * from foo;
--------------
select * from foo
--------------
+------+
| id |
+------+
| 55 |
| 131 |
+------+
2 rows in set (0.00 sec)
如果使用默认配置，你将无法通过GreenSQL防火墙丢弃数据表。这倒无妨，因为表结构不太可能经常改变，更不可能通过Web界面改 变。 $ mysql --verbose -h 127.0.0.1 -P 3305 test
Welcome to the MySQL monitor. Commands end with ; or \g.
mysql> select * from foo;
--------------
select * from foo
--------------
+------+
| id |
+------+
| 55 |
| 131 |
+------+
2 rows in set (0.00 sec)
mysql> drop table foo;
--------------
drop table foo
--------------
Query OK, 0 rows affected (0.00 sec)
mysql> select * from foo;
--------------
select * from foo
--------------
+------+
| id |
+------+
| 55 |
| 131 |
+------+
2 rows in set (0.01 sec)
注入测试看来没有如所期望的那样正常工作。第一次测试是在条件一直为真时删除表。这会清除表内的所有数据，留下一个空表。默 认地此查询会通过防火墙进行： $ mysql --verbose -h 127.0.0.1 -P 3305 test
mysql> delete from foo where 1=1;
--------------
delete from foo where 1=1
--------------
Query OK, 2 rows affected (0.00 sec)
mysql> select * from foo;
--------------
select * from foo
--------------
Empty set (0.00 sec)
对于上面的SQL删除命令来说，/var/log/greensql.log文件包含了下面的信息： SQL_DEBUG: QUERY command[]: delete from foo where 1=1
SQL_DEBUG: AFTER NORM : delete from foo where ?=?
SQL_DEBUG: RISK : 0
/etc/greensql/greensql.conf文件准许你设置某些内容的风险程度。例如，你可以将10指定给union关键字使用，或者在查询中使用 直接的变量比较（如同1=2之类的东西）。这些变量包括“block_level = 30”，所以RISK大于30的任何查询都不转发给MySQL服务器 。为了让GreenSQL标记出上面的查询，笔者将risk_var_cmp_var 和 risk_always_true从默认的30增加至150。但很不幸，这次查询 看起来仍是风险为零。 SQL_DEBUG: QUERY command[]: delete from foo where id=181 or 1=1
SQL_DEBUG: AFTER NORM : delete from foo where id=? or ?=?
SQL_DEBUG: RISK : 0
SQL_DEBUG: QUERY command[]: delete from s where comment = 'whatever' or '1'='1'
SQL_DEBUG: AFTER NORM : delete from s where comment = ? or ?=?
SQL_DEBUG: RISK : 0
笔者做了许多尝试,结果都是一样的,即GreenSQL都将前面的不怀好意的查询的风险看成是零,笔者又试用了一下SELECT查询。这竟然 是使GreenSQL工作的一个关键，即可以阻止恶意查询，如日志文件的一个片断部分所示： SQL_DEBUG: QUERY command[]: select * from folks where name='sam' or '1'='1'
SQL_DEBUG: AFTER NORM : select * from folks where name=? or ?=?
DEBUG: Query has 'or' token
DEBUG: Variable comparison only
SQL_DEBUG: RISK : 35