#1148 Keep query results readable after an environment rename Pull request opened by javuto Keep query results readable after an environment rename Problem Since part 3 (#1147), query results are judged against the caller's lowest tier across every environment the query targets. Environment targets are stored as the value that was submitted, usually the environment name. Renaming an environment moved its nodes and posture rows but not those stored targets. So after a rename: • every earlier query's environment target pointed at a name that no longer exists; • that unknown environment counted as "no access"; • results showed zero rows for everyone, including superusers. It failed closed, so nothing leaked, but it looked like data loss. There was a smaller related issue. A new environment created with the old name would inherit those stale targets, and results would be judged against an environment that never held them. What changes

EnvManager.UpdateFields

already moves name-keyed rows (

osquery_nodes

,

node_posture

) when it renames an environment. In the same transaction, it now rewrites

distributed_query_targets

rows where

type = 'environment'

and

value

is the old name. • Targets stored as the environment UUID are left alone, since a rename doesn't change the UUID. • Other target types (platform, uuid, host, tag) are not touched. • No schema change. Security and operational impact • Results from queries that existed before a rename are visible again to the users who could see them before. • The rule is unchanged: results are judged against the caller's lowest tier across the targeted environments. • osctrl-tls is not changed. Validation • New

TestUpdateFieldsRenameMovesQueryTargets

checks that: • the old-name environment target moves to the new name; • the UUID target, a platform target with the same text, and another environment's target are unchanged. • The test failed before the fix and passes after. •

go test ./...

passes. jmpsec/osctrl