Page MenuHomePhabricator

Lock policy queries to their applications
ClosedPublic

Authored by epriestley on Oct 20 2013, 1:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 19, 5:13 PM
Unknown Object (File)
Fri, Dec 13, 4:38 AM
Unknown Object (File)
Wed, Dec 11, 6:23 PM
Unknown Object (File)
Wed, Dec 11, 2:51 AM
Unknown Object (File)
Mon, Dec 9, 3:29 PM
Unknown Object (File)
Mon, Dec 9, 4:19 AM
Unknown Object (File)
Mon, Dec 9, 4:19 AM
Unknown Object (File)
Mon, Dec 9, 4:19 AM
Subscribers

Details

Reviewers
btrahan
Commits
Restricted Diffusion Commit
rP2a5c987c714d: Lock policy queries to their applications
Summary

While we mostly have reasonable effective object accessibility when you lock a user out of an application, it's primarily enforced at the controller level. Users can still, e.g., load the handles of objects they can't actually see. Instead, lock the queries to the applications so that you can, e.g., never load a revision if you don't have access to Differential.

This has several parts:

  • For PolicyAware queries, provide an application class name method.
  • If the query specifies a class name and the user doesn't have permission to use it, fail the entire query unconditionally.
  • For handles, simplify query construction and count all the PHIDs as "restricted" so we get a UI full of "restricted" instead of "unknown" handles.
Test Plan
  • Added a unit test to verify I got all the class names right.
  • Browsed around, logged in/out as a normal user with public policies on and off.
  • Browsed around, logged in/out as a restricted user with public policies on and off. With restrictions, saw all traces of restricted apps removed or restricted.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

LGTM. I dunno how you track TODOs but I wouldn't want to lose 'em if we need a super serious T603 v2 or what have you.