FedWiki maintenance can change or delete a newer site that reuses a deleted site's name #301

New Issue

2026-10-30T22:44:41Z

cgalo5758 commented

2026-10-30 22:44:41 +00:00

What happens

The console's periodic FedWiki maintenance reads sites before it changes them: its quota sweep makes sites over a plan's limit read-only, and its sync copies the wiki farm's state into the console. Both later find a site again by its name, which can be reused, instead of by the id they read.

While the quota sweep waits on its farm call, a member can permanently delete a listed site and create another with the same name. The sweep can then write the old site's status onto the new site and count the usage against the old site's organization: parkSite, reactivateSite and sweepLocally check the listed id before the farm call, then write by name (internal/integrations/fedwiki/workflows/reconcile.go:269, :309, :369).

The sync has the same gap in its status write (writeStatus, internal/integrations/fedwiki/workflows/sync.go:513, which locks the current name but checks requests on the id it read) and in its removal of System sites the farm no longer lists (deleteFarmAbsent, sync.go:559, which checks ownership on the row it read and deletes by name). System sites are sites the console found on the farm with no member owner. Those two paths need a deletion between the read and the write that no member request causes, such as a hand-run SQL statement; the removal path can then delete a member's new site, recount the old organization's usage and release the old site's domain record, which links its name to its site.

What should happen

Maintenance writes or deletes only the site id it read, rechecking eligibility under that row's lock. A missing or replaced site is left alone, and any recount or domain release concerns the row actually changed.

Where

internal/integrations/fedwiki/workflows/reconcile.go; internal/integrations/fedwiki/workflows/sync.go

Why it matters

A newly created site can receive a status nobody asked for or lose its console record, and an organization's usage can be counted against the wrong organization.

### What happens The console's periodic FedWiki maintenance reads sites before it changes them: its quota sweep makes sites over a plan's limit read-only, and its sync copies the wiki farm's state into the console. Both later find a site again by its name, which can be reused, instead of by the id they read. While the quota sweep waits on its farm call, a member can permanently delete a listed site and create another with the same name. The sweep can then write the old site's status onto the new site and count the usage against the old site's organization: `parkSite`, `reactivateSite` and `sweepLocally` check the listed id before the farm call, then write by name (`internal/integrations/fedwiki/workflows/reconcile.go:269`, `:309`, `:369`). The sync has the same gap in its status write (`writeStatus`, `internal/integrations/fedwiki/workflows/sync.go:513`, which locks the current name but checks requests on the id it read) and in its removal of System sites the farm no longer lists (`deleteFarmAbsent`, `sync.go:559`, which checks ownership on the row it read and deletes by name). System sites are sites the console found on the farm with no member owner. Those two paths need a deletion between the read and the write that no member request causes, such as a hand-run SQL statement; the removal path can then delete a member's new site, recount the old organization's usage and release the old site's domain record, which links its name to its site. ### What should happen Maintenance writes or deletes only the site id it read, rechecking eligibility under that row's lock. A missing or replaced site is left alone, and any recount or domain release concerns the row actually changed. ### Where `internal/integrations/fedwiki/workflows/reconcile.go`; `internal/integrations/fedwiki/workflows/sync.go` ### Why it matters A newly created site can receive a status nobody asked for or lose its console record, and an organization's usage can be counted against the wrong organization.

cgalo5758 added the

kind

bug

area/fedwiki labels 2026-10-30 22:44:41 +00:00

cgalo5758 referenced this issue from a commit

2026-10-30 23:08:31 +00:00

Archive the one purchase rule and the site-bound requests changes

Sign in to join this conversation.