Opened 3 weeks ago
Closed 3 days ago
#37203 closed Bug (fixed)
inspectdb doesn't account for normalized field names when building CompositePrimaryKey
| Reported by: | Mundur | Owned by: | Mundur |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | dev |
| Severity: | Normal | Keywords: | inspectdb, compositeprimarykey |
| Cc: | Mundur | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
inspectdb generates Python model source from database metadata. Most generated metadata already uses repr-style escaping, but two paths still interpolate database-provided values directly into generated source text:
- composite primary-key column names in models.CompositePrimaryKey(...)
- table names and exception messages emitted in introspection-error comments
This can produce invalid or unintended generated model code for unusual database schemas containing quotes or newlines.
Proposed fix:
- render CompositePrimaryKey column names with repr()
- render introspection-error table names/messages with repr-style output
- add regression tests for both paths
A pull request with tests is available:
https://github.com/django/django/pull/21581
Change History (8)
comment:1 by , 3 weeks ago
| Description: | modified (diff) |
|---|
comment:2 by , 3 weeks ago
| Keywords: | inspectdb compositeprimarykey added |
|---|---|
| Patch needs improvement: | set |
| Summary: | Escaped database metadata in inspectdb generated model code → inspectdb doesn't account for normalized field names when building CompositePrimaryKey |
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 3 weeks ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:4 by , 3 weeks ago
Thanks for the pull request. When the comments are addressed, please unset "Patch needs improvement".
comment:6 by , 4 days ago
| Patch needs improvement: | unset |
|---|---|
| Triage Stage: | Accepted → Ready for checkin |
Thanks for the report. Your test demonstrates a more serious issue than the invalid python identifiers -- we're calculating the field names for the positional arguments to
CompositePrimaryKeybefore those field names are potentially rewritten innormalize_col_name(). In other words, your provided test asserts that the first positional argument isx', 'safe');__import__('os').system('echo unsafe')#, but it should really bex_safe_import_os_system_echo_unsafe_field.We can fix the
repr()inconsistencies you found along the way, but I'd like to reframe this ticket along the above lines. If you continue with this, please assign yourself in the owner field, and please also choose a simpler example -- the given example is giving "security exploit", but that's a distraction here (deploying a malicious column name implies full system compromise already).