The `default` user in the `users.xml` file that ships with ClickHouse has
`access_management` and `named_collection_control` enabled, but not
`show_named_collections_secrets`, so it does not have the complete set of
privileges. A user can only grant the privileges that they have themselves,
so `GRANT ALL ON *.* TO clickhouse_admin WITH GRANT OPTION` - the query the
documentation tells you to run when bootstrapping a SQL administrator - is
rejected with:
Not enough privileges. To execute this query, it's necessary to have the
grant ALL ON *.* WITH GRANT OPTION.
(Missing permissions: SHOW NAMED COLLECTIONS SECRETS ON *)
Add `show_named_collections_secrets` commented out next to the other two
settings in `programs/server/users.xml` and `programs/server/embedded.xml`,
explaining both why it is disabled and what it costs, so that the setting is
discoverable where people look for it. The behaviour is unchanged: reading
back the credentials that are already stored in named collections stays a
separate privilege from managing the collections.
Also fix the documentation, which asks for a `show_named_collections`
setting that `UsersConfigParser` does not read - it was folded into
`NAMED COLLECTION ADMIN` - and which claimed that SQL-driven access control
is disabled by default for every user, and add reference sections for
`named_collection_control` and `show_named_collections_secrets`.
Closes: https://github.com/ClickHouse/ClickHouse/issues/47092
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The comments in `users.xml`, `users.yaml.example` and the user settings doc said
that an omitted user name always falls back to `default`, which is now governed by
the `default_session_user` server setting. The composable protocols doc implied that
`default_session_user` applies to all `prometheus` handlers, while the metrics
exposition endpoints (including Keeper metrics-only endpoints) never authenticate
and ignore the setting.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The problem is that async_insert is checked during parsing, to know what
to send to the server, even before server settings available. And this
leads to "Unknown packet 11 from server" errors.
So, first approach will be to simply ignore async_insert for
apply_settings_from_server, but this setting is interesting to apply
from the server (since this may have performance impact).
Another is to detect what part of the query we should after server
settings had been received, this patch follows this approach.
