[mysql] Name REFERENCES in the schema collection privileges warning - #24739
[mysql] Name REFERENCES in the schema collection privileges warning#24739azhou-datadog wants to merge 1 commit into
Conversation
bb2dc33 to
efa6afe
Compare
|
|
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 2f6abc9 | Docs | Datadog PR Page | Give us feedback! |
efa6afe to
6210174
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 62101740f2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| "to view table metadata. The datadog user needs REFERENCES (or SELECT) privileges on the " | ||
| "tables.".format(len(db_infos)) |
There was a problem hiding this comment.
This warning now tells users to grant REFERENCES, but the in-repo generated sample config still says schema collection only collects tables with SELECT privileges (mysql/datadog_checks/mysql/data/conf.yaml.example:337, generated from mysql/assets/configuration/spec.yaml:475). Users configuring from the shipped sample will continue granting broader read access and get guidance that contradicts this new Agent warning, so the config spec/sample should be updated along with the warning.
Useful? React with 👍 / 👎.
6210174 to
8a0f8c0
Compare
MySQL only exposes a table in INFORMATION_SCHEMA to users holding a privilege on it, which is why schema collection currently asks customers for SELECT on their tables. The REFERENCES privilege satisfies that same visibility check without granting any ability to read table data, so the insufficient-privileges warning now points at it instead of SELECT. The config spec carried the same SELECT-only guidance in five places - the collect_schemas description, its deprecated schemas_collection twin, and the three size-metric options - so update those too and regenerate the sample. Otherwise anyone configuring from the shipped conf.yaml.example would keep granting broader read access than the Agent needs, and would get advice that contradicts the new warning. Verified that the size-metric queries return identical results under REFERENCES and SELECT on Percona 8.4.10, MariaDB 11.4.12 and MySQL 5.6.51, so the wording change is accurate for those options too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8a0f8c0 to
2f6abc9
Compare
Validation ReportAll 21 validations passed. Show details
|
1 participant
Supersedes #24737, which could not be reopened after its branch was rewritten to drop the unrelated commits it had picked up.
What does this PR do?
Points the schema-collection insufficient-privileges warning at the
REFERENCESprivilege instead ofSELECT.MySQL exposes a table in
INFORMATION_SCHEMAonly to users that hold some privilege on it — that is why schema collection currently asks customers toGRANT SELECT ON *.*, and why the setup docs have to explain in prose that the Agent doesn't actually read their data.REFERENCESsatisfies the same visibility check and grants no ability to read (or write) anything.No query changes: the collected payload is identical under either privilege.
Motivation
Requiring
SELECTon customer tables is the main setup hurdle for MySQL schema collection and blocks enabling it by default. A spike verified thatREFERENCESproduces a byte-identical schema payload while leaving the Agent unable to read table data:SELECTbaseline on MySQL 5.6.51, 5.7.44, 8.0.45, 8.4.3, 9.7.2, Percona 8.4.10 and MariaDB 10.11.18, 11.4.12.mysql_databasespayload the Agent puts on the wire is unchanged after swapping the grant (18 tables / 97 columns / 41 indexes / 4 FKs / 5 partitions, empty diff), whileSELECT * FROM <table>as the Agent user returnsERROR 1142.REFERENCESalone cannot create a foreign key: that needsCREATE/ALTERon the referencing table, which thedatadoguser does not have.rds_superuser_roleincludes itWITH GRANT OPTION), Cloud SQL, and Azure MySQL.Worth noting:
tests/conftest.py:606already grantsREFERENCESto the test user, with the comment "needed to query INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS in mariadb 10.5 and above". That requirement was worked around in the fixture but never surfaced to customers, so MariaDB users following the docs today collect foreign keys without theirON UPDATE/ON DELETEactions.One behavioural consequence for the docs rather than the code: with
REFERENCESinstead ofSELECT, theSTATEMENTexplain strategy (a directEXPLAINas thedatadoguser) no longer works, so explain plans depend on theexplain_statementdefiner procedures that setup already prescribes. Verified both halves in a sandbox.Additional Notes
Docs counterpart: DataDog/documentation#38606.
Deliberately not in this PR, to be handled separately:
SQL_FOREIGN_KEYSaggregatesreferenced_column_nameswithgroup_concatand noORDER BY, unlike thecolumn_namesaggregate beside it, so composite foreign keys report their referenced columns in a non-deterministic order (reproduced asa,bvsb,aon the same constraint across MySQL 5.6 and MariaDB).test_collect_schemascurrently sorts that field before comparing, which hides it.Review checklist (to be filled by reviewers)
qa/skip-qalabel if the PR doesn't need to be tested during QA.backport/<branch-name>label to the PR and it will automatically open a backport PR once this one is merged