Tree: 8136691ad3

cached-config-operations

main

revert-7033-patch-1

test_dylint

v2-registration

0.10.0

0.11.0

0.12.0

0.13.0

0.9.0

1.0.0

1.1.0

1.10.0

1.11.0

1.12.0

1.13.0

1.13.1

1.14

1.14.1

1.14.2

1.15.0

1.15.1

1.16.0

1.16.1

1.16.2

1.16.3

1.17.0

1.18.0

1.19.0

1.2.0

1.20.0

1.21.0

1.22.0

1.22.1

1.22.2

1.23.0

1.23.1

1.24.0

1.25.0

1.25.1

1.25.2

1.26.0

1.27.0

1.28.0

1.28.1

1.29.0

1.29.1

1.29.2

1.3.0

1.30.0

1.30.1

1.30.2

1.30.3

1.30.4

1.30.5

1.31.0

1.32.0

1.32.1

1.32.2

1.32.3

1.32.4

1.32.5

1.32.6

1.32.7

1.33.0

1.33.1

1.33.2

1.34.0

1.34.1

1.34.2

1.34.3

1.35.0

1.35.1

1.35.2

1.35.3

1.35.4

1.35.5

1.35.6

1.35.7

1.35.8

1.36.0

1.37.0

1.37.1

1.4.0

1.5.0

1.6.0

1.6.1

1.7.0

1.8.0

1.9.0

1.9.1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '8136691ad3'

${ noResults }

Commit Graph

2 Commits (8136691ad32623c949287459cb0006c499cc0c59)

Author	SHA1	Message	Date
tom27052006	8136691ad3	Close a manage-grant laundering path and harden the rollback tooling Follow-up to the previous two commits, all four issues were introduced by them: - The legacy `access_all`-group authority was accepted by `caller_may_grant_collection_manage`, so a Custom member with manageGroups + editAnyCollection could create an access_all group holding itself, use the derived authority to persist `collections_groups.manage`, then leave the group and keep collection deletion without ever holding deleteAnyCollection. The clamp now takes only a real stored grant again, and the legacy exception is limited to members holding none of the three collection permissions -- which is the shape the migration leaves a group-derived Manager in, and never a member who can create such a group in the first place. - `Collection::to_json_details` reported `manage: false` for a member reaching every collection even when a real grant existed, so the client rendered controls that disagree with the guards. Both the cached and the uncached path now read the effective grant. - The SQLite rollback script continued after a failed statement, so a second run dropped `users_organizations` and committed an empty replacement. It now sets `.bail on`, refuses up front unless the permission columns are present, and the README documents `-bail` instead of claiming the run is atomic regardless. - The downgrade acknowledgement was never consumed, so one approval authorized every later revert. It is now dropped by the revert it permits and cleared again on re-upgrade.	6 days ago
tom27052006	7542f3d4e9	Provide a supported rollback path for the Custom-role change Vaultwarden only ever applies pending migrations, so putting an older image back leaves it facing a schema whose `access_all` column is gone -- and it refuses to start. The downgrade guard did not help there either: it only ever blocked `diesel migration revert`, which a self-hosted install cannot run. - tools/custom_role_rollback/ holds a self-contained script per backend that restores the pre-PR schema, folds Custom back onto Manager, and drops the seven ledger rows, so the older version starts again. SQLite rebuilds the table instead of using DROP COLUMN, for the same 3.35 reason as the forward migration. - The guard now states its terms instead of being a dead end: create __vw_allow_custom_role_downgrade and the revert goes through, so the data loss is acknowledged rather than merely prevented. - README documents what the old schema cannot represent, including the two values that cannot be reconstructed: Owner/Admin return with access_all set, and a plain User's former access_all stays materialized as the per-collection assignments the upgrade wrote.	6 days ago