Semantic view tools bypass permission middleware; if/elif logic error in validators
Three related bugs in the SQL permission validation system:
-
validate_semantic_view_tool exists in semantic_manager/tools.py but is never imported or called from CheckQueryType middleware in server_utils.py. All semantic tools (list_semantic_views, query_semantic_view, etc.) bypass configured sql_statement_permissions entirely.
-
Both validate_semantic_view_tool and validate_object_tool use if where elif is needed, breaking the intended guard when both allow/disallow lists are empty. Compare with validate_sql_type in query_manager/tools.py which uses the correct elif chain.
-
write_semantic_view_query f-string interpolates where_clause and order_by directly into SQL without validation, unlike identifiers which use bind variables.
Steps to Reproduce
- Configure
sql_statement_permissions with empty allow/disallow lists (should block everything)
- Call
list_semantic_views -- succeeds when it should be blocked
- Call
create_object -- correctly blocked by middleware
Relevant Code
server_utils.py -- no semantic handler:
if tool_name.lower() == "run_snowflake_query" ...:
statement_type, valid = validate_sql_type(...)
elif tool_name.lower().startswith("create") or tool_name.lower().startswith("drop"):
statement_type, valid = validate_object_tool(...)
# semantic tools fall through here
else:
valid = True
semantic_manager/tools.py and object_manager/tools.py -- if should be elif:
if len(sql_allow_list) == 0 and len(sql_disallow_list) == 0:
valid = False
if func_type in sql_allow_list: # should be elif
valid = True
semantic_manager/tools.py -- unvalidated interpolation:
if where_clause:
statement += f" WHERE {where_clause}"
Semantic view tools bypass permission middleware; if/elif logic error in validators
Three related bugs in the SQL permission validation system:
validate_semantic_view_toolexists insemantic_manager/tools.pybut is never imported or called fromCheckQueryTypemiddleware inserver_utils.py. All semantic tools (list_semantic_views,query_semantic_view, etc.) bypass configuredsql_statement_permissionsentirely.Both
validate_semantic_view_toolandvalidate_object_tooluseifwhereelifis needed, breaking the intended guard when both allow/disallow lists are empty. Compare withvalidate_sql_typeinquery_manager/tools.pywhich uses the correctelifchain.write_semantic_view_queryf-string interpolateswhere_clauseandorder_bydirectly into SQL without validation, unlike identifiers which use bind variables.Steps to Reproduce
sql_statement_permissionswith empty allow/disallow lists (should block everything)list_semantic_views-- succeeds when it should be blockedcreate_object-- correctly blocked by middlewareRelevant Code
server_utils.py-- no semantic handler:semantic_manager/tools.pyandobject_manager/tools.py--ifshould beelif:semantic_manager/tools.py-- unvalidated interpolation: