Bug 34867

Summary: DatabaseAuthorizer should allow the use of CREATE/DROP VIRTUAL TABLE
Product: WebKit Reporter: Dumitru Daniliuc <dumi>
Component: New BugsAssignee: Dumitru Daniliuc <dumi>
Status: RESOLVED FIXED    
Severity: Normal CC: ericu, michaeln, scarybeasts
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
patch
none
patch dglazkov: review+, dumi: commit-queue-

Dumitru Daniliuc
Reported 2010-02-11 17:46:31 PST
Chromium needs virtual tables in order to use FTS. I'm not sure why CREATE/DROP VIRTUAL TABLE have been disabled in WebKit since forever, but it seems to me like these instructions don't pose any security threat and should be allowed.
Attachments
patch (9.72 KB, patch)
2010-02-11 18:29 PST, Dumitru Daniliuc 		no flags
DetailsFormatted DiffDiff
patch (1.96 KB, patch)
2010-02-16 17:08 PST, Dumitru Daniliuc 		dglazkov: review+
dumi: commit-queue-
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Dumitru Daniliuc
Comment 1 2010-02-11 18:29:49 PST
Created attachment 48602 [details] patch
Dumitru Daniliuc
Comment 2 2010-02-16 17:08:17 PST
Created attachment 48849 [details] patch Oops, uploaded the wrong patch.
Michael Nordman
Comment 3 2010-02-17 12:31:51 PST
If there is no reason to disallow them, why filter on moduleName? Maybe just denyBasedOnTableName(tableName) and not test the 'moduleName' at all.
Chris Evans
Comment 4 2010-02-17 14:17:37 PST
Interesting. If there's no user demand for direct creation of virtual tables, I'd be tempted to play it safe, and restrict them to internal usage by fts2.
Dimitri Glazkov (Google)
Comment 5 2010-02-18 13:21:28 PST
Comment on attachment 48849 [details] patch ok.
Dumitru Daniliuc
Comment 6 2010-02-19 19:10:06 PST
Landed as r54990.
Note You need to log in before you can comment on or make changes to this bug.