Marton Greber has posted comments on this change. ( http://gerrit.cloudera.org:8080/24864 )
Change subject: Require authentication for REST catalog DDL ...................................................................... Patch Set 1: (2 comments) Test coverage gaps: - The new validator branch (master.cc:188) has no test: a short negative startup test asserting the master refuses to start with --enable_rest_api=true and no SPNEGO / password-file / anonymous flag. - No coverage for the password-file path. A test that password-file auth is accepted for POST but behaves correctly for PUT/DELETE would have surfaced the gap above. http://gerrit.cloudera.org:8080/#/c/24864/1/src/kudu/master/master.cc File src/kudu/master/master.cc: http://gerrit.cloudera.org:8080/#/c/24864/1/src/kudu/master/master.cc@188 PS1, Line 188: if (FLAGS_enable_rest_api && !FLAGS_webserver_require_spnego && The validator treats --webserver_password_file as a sufficient auth mode for the whole REST API. But the webserver only passes it to squeasel as global_auth_file, and squeasel runs digest auth (check_authorization) only for non-PUT/DELETE requests: squeasel.c:3559 } else if (!is_put_or_delete_request(conn) && !check_authorization(conn, path)) { PUT/DELETE are instead gated by is_authorized_for_put(), which reads put_delete_auth_file — a config Kudu never sets. So the begin_request callback (our handler) fires for PUT/DELETE with remote_user unset. Net effect with password-file-only auth: GET/POST are authenticated, but PUT (AlterTable) and DELETE (DeleteTable) always hit the empty-username path and now get 401. It fails closed (good, not a security regression), but it means password-file auth silently makes the two mutating DDL endpoints unusable, while the validator/log message advertises it as a valid way to secure the REST API. Can you confirm this behavior, and either couple password-file support to put_delete_auth_file or narrow the log message to note SPNEGO is required for Alter/Delete? http://gerrit.cloudera.org:8080/#/c/24864/1/src/kudu/master/rest_catalog_path_handlers.cc File src/kudu/master/rest_catalog_path_handlers.cc: http://gerrit.cloudera.org:8080/#/c/24864/1/src/kudu/master/rest_catalog_path_handlers.cc@413 PS1, Line 413: PrintTableObject(output, table_id, status_code); The comment says setting the success code before PrintTableObject lets "a concurrent delete racing GetTableInfo … overwrite it with the real error code." But CatalogManager::GetTableInfo() returns Status::OK() with a null table when the table is gone (catalog_manager.cc), and PrintTableObject only branches on !status.ok() - it then does TableMetadataLock l(table.get(), ...) on a null pointer. So in exactly the concurrent-delete race the comment cites, this looks like it dereferences null and crashes rather than returning an error code. The reorder itself is harmless/fine, but either PrintTableObject should null-check table (return NotFound), or the comment should be corrected so it doesn't claim to handle a race it doesn't. Worth verifying whether this null-deref is reachable. -- To view, visit http://gerrit.cloudera.org:8080/24864 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Ib0112638a3462c84e6366b881c9229a334ad3c25 Gerrit-Change-Number: 24864 Gerrit-PatchSet: 1 Gerrit-Owner: Gabriella Lotz <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Marton Greber <[email protected]> Gerrit-Comment-Date: Fri, 18 Sep 2026 11:16:43 +0000 Gerrit-HasComments: Yes
