Page MenuHomePhabricator

Update "bin/policy unlock" to be more surgical, flexible, modular, and modern

Authored by epriestley on Mar 7 2019, 4:41 AM.



See PHI1115. Ref T13249. Currently, you can bin/policy unlock objects which have become inaccessible through some sort of policy mistake.

This script uses a very blunt mechanism to perform unlocks: just manually calling setXPolicy() and then trying to save() the object. Improve things a bit:

  • More surgical: allow selection of which policies you want to adjust with "--view", "--edit", and "--owner" (potentially important for some objects like Herald rules which don't have policies, and "edit-locked" tasks which basically ignore the edit policy).
  • More flexible: Instead of unlocking into "All Users" (which could be bad for stuff like Passphrase credentials, since you create a short window where anyone can access them), take a username as a parameter and set the policy to "just that user". Normally, you'd run this as bin/policy unlock --view myself --edit myself or similar, now.
  • More modular: We can't do "owner" transactions in a generic way, but lay the groundwork for letting applications support providing an owner reassignment mechanism.
  • More modern: Use transactions, not raw set() + save().

This previously had some hard-coded logic around unlocking applications. I've removed it, and the new generic stuff doesn't actually work. It probably should be made to work at some point, but I believe it's exceptionally difficult to lock yourself out of applications, and you can unlock them with bin/config set phabricator.application-settings ... anyway so I'm not too worried about this. It's also hard to figure out the PHID of an application and no one has ever asked about this so I'd guess the reasonable use rate of bin/policy unlock to unlock applications in the wild may be zero.

Test Plan
  • Used bin/policy unlock to unlock some objects, saw sensible transactions.

Diff Detail

rP Phabricator
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Mar 7 2019, 4:41 AM
epriestley requested review of this revision.Mar 7 2019, 4:43 AM
amckinley accepted this revision.Mar 7 2019, 8:14 PM
amckinley added inline comments.

Maybe remove this option until PhabricatorUnlockEngine ::newUnlockOwnerTransaction() gets implemented?

This revision is now accepted and ready to land.Mar 7 2019, 8:14 PM

Oh, I didn't see D20257. Carry on.

epriestley edited the summary of this revision. (Show Details)Mar 7 2019, 8:16 PM
This revision was automatically updated to reflect the committed changes.