Suppress bad SQL in TracReports

[trac-ja@…]

TracReports allows all SQL and query: semantec now, and user that granted REPORT_MODIFY can't write only SELECT, but also INSERT, UPDATE, DELETE, CREATE and DROP. I think it should allows only SELECT and query:.

[trac-ja@…]

Patch against Trac-0.11b1

[Christian Boos]

Those "wrong" queries should normally never get commit'ted, so normally no harm can be done (well, except for the DROP and CREATE with SQLite, which don't need a commit to be effective, IIRC).

[trac-ja@…]

Replying to cboos:

Those "wrong" queries should normally never get commit'ted, so normally no harm can be done (well, except for the DROP and CREATE with SQLite, which don't need a commit to be effective, IIRC).

Yes, sorry, I checked with PostgreSQL.

When Trac project has PostgreSQL backend, these queries will run.

create table xxx (aaa char);
commit;
select * from pg_tables

delete from session;
commit;
select * from session

[John Hampton]

I'm +1 for the patch. While one should trust the users that they give REPORT_MODIFY privs to, it is not unwise to prevent the possible damage

[John Hampton]

Closing the ticket as won't fix after discussion with athomas and nkantrowitz. While the patch will catch some of the cases, it won't catch all of them. In order to catch all of the cases where a report could have bad SQL would require a full SQL parser and hence is not feasible. The consensus is that a half-implementation is worse than no implementation at all. The fact remains that if you give your users REPORT_MODIFY or REPORT_ADMIN perms, you need to trust those users to not screw up.