Page MenuHomePhabricator

Add custom policy to access denied message
Open, LowestPublic

Description

When a (logged in) user tries to visit a restricted task, like T161995, they see "This object has a custom policy controlling who can take this action.
", which doesn't inform. Maybe it's intentional, but I feel revealing custom policy doesn't reveal much.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 31 2019, 11:45 PM
Aklapper closed this task as Declined.Sep 1 2019, 9:15 AM
Aklapper edited projects, added Phabricator (Upstream); removed Phabricator.

It would reveal which accounts / groups can access hence declining. See T187051 for similar discussions.

Restricted Application added a project: Upstream. · View Herald TranscriptSep 1 2019, 9:15 AM

@Aklapper Granted, but if the policy is not custom, that already happens (AFAIK). I don't see an explanation why is custom policy more sensitive than project policy.

Oops, you're right. I guess it has to do with how to list/visualize a lost of things then, plus I am sure we still do not want to list specific individual accounts.

Urbanecm reopened this task as Open.Sep 2 2019, 1:00 PM

Oops, you're right.

Thank you.

I guess it has to do with how to list/visualize a lost of things then,

Probably, but not a reason for declining, I guess.

plus I am sure we still do not want to list specific individual accounts.

It can be "custom view policy" is a link, showing a popup, saying "The following people have access: a) members of Security b) subscribers c) task author". We don't set custom view policy for user anyway, unless it is the task author. Hard to fix (Technical-Debt, I guess), but "add a rule 'Is task author'" can be a blocker for this, then we can migrate all our rules and this would be doable. It's not a reason for declining, but it's low(est), granted. Even those things should be tracked through ;).

Also, keep in mind the view policies (and their history) is public, if the task is published. See T222014 as an example. I can see "Krenair changed the visibility from "Public (No Login Required)" to "Custom Policy"", Custom Policy is clickable, and it shows this:

My username is because I authored the task, only. However, that's not necessary, per (non-public) T194204 and the fact I can view it, but not edit. If I click "edit task", it says Members of the project "acl*security_team" can take this action., and The owner of a task can always view and edit it.. If it's true, it's not necessary to add task author :-). If it's not, it's (another) task.

Subscribers of "internal id" is pretty ambigous, and also can be published, given mere (internal) IDs are not private in any means. So, this actually happens, but not in this context. Hence, reopening. Feel free to prioritize/stall, as you see fit.

Aklapper triaged this task as Lowest priority.Sep 2 2019, 1:48 PM
epriestley added a subscriber: epriestley.EditedSep 3 2019, 9:16 PM

See also T211498.

In the use case described in T211498, the viewer has permission to view (and possibly edit) the task, so there's obviously no (security/policy) reason to hide the policy details from them. In that case, I think we should render all the custom policy rules inline. This is just an issue of making the rendering code more sophisticated/detailed.

In the case where the user can't see the task (here), I'm less sure things are quite as clear-cut. I could imagine a policy like this:

Allow members of project: Security
Allow users: alice, bailey

...where @alice is publicly known to be an expert on file uploads and @bailey is publicly known to be an expert on SVG or something. This doesn't leak a ton of information and an attacker would need to make a lot of inferences (e.g., this is possibly a security issue with uploading SVG files), but this is generally more information about the content of the object than we normally allow users who can't see the object to learn. (See also T187051, referenced above.)

I'm inclined to think that this dialog should actually err on the side of disclosing less information than it currently does when the viewer can't see the object. I think the disclosure today is fairly mild (even if we imagine disclosing all the rules in custom policies), but I'm also not sure how valuable it is to know that some T12345 (which you can't see) is visible to members of project X vs members of project Y. Presumably, your action is always to go back to wherever you got the link from and say "I can't see that, can you add me?" or whatever, and that action presumably doesn't change very frequently even if you know the policy details.

Are there specific cases where knowing policy details changes how you interact with objects? My expectation is that no matter what the dialog says, you always return to the context where the object was linked and ask someone from that context to give you access if you need access, so interactions are basically the same whether the dialog says "Sorry, you can't see this" or details every aspect of every policy rule.

Are there specific cases where knowing policy details changes how you interact with objects? My expectation is that no matter what the dialog says, you always return to the context where the object was linked and ask someone from that context to give you access if you need access, so interactions are basically the same whether the dialog says "Sorry, you can't see this" or details every aspect of every policy rule.

You kinda answered your question. I can ask "someone", but who is that someone? Phabricator admins? They aren't all-powerful, and can get permission denied. Member of some acl project (like Security)? Yes, but...I am currently a member of that project, what if I don't see a task then? Ask just "someone"? Well, that doesn't help much. Being able to see projects-only would be extremely useful, because I would be able to ask a member of that project, through.

I understand it leaks something otherwise non-public, granted, that's a point. However, it a) happens b) doesn't leak much, as you mentioned. See Wikipedia's error message at https://en.wikipedia.org/wiki/Special:Block/Martin_Urbanec_(test), for instance (try it in inkognito window, if you have block right at en.wikipedia.org). It says "The action you have requested is limited to users in the group: Administrators.". That's telling info that's useful, althrough it also "leaks" a list of accounts with admin rights you can try, see list of en.wikipedia administrators. Custom user rules can be excluded.

I know many users use Phabricator privately, but Wikimedia doesn't. Anyone can join, and request things or discuss tasks here. If they got to a reference to a task, and I need to know why "something" happened, it makes sense to ask what the task is about, but I need to know who/ere to ask. I can ask just somewhere, but that might get me a wrong answering person.

After all, just relevaling it is custom policy reveals somethng. Given almost all WIkimedia policies are "custom", it does say something, but not useful. This should be changed either to reveal full policy, or not reveal even project policy, when it says it is available to Security. List of Security access people is available at project tag page, and it is abusable as much as any usernamelist. This is publicly readable phabricator, and I don't see a reason why to not reveal that, when we reveal even only list of all users.

Does that explain it to you?

You kinda answered your question. I can ask "someone", but who is that someone?

My expectation is that you usually learn about a task in some context which you can use to figure out who to ask -- like the comment thread on another task. For example, maybe some user "Alice" posts a comment on T123 like this:

There's some important discussion related to this subject in T456.

In this case, if you can't see T456, you know that Alice can see T456 and believes it's relevant to the discussion, so you can ask her to give you access or summarize what she thought was important. I imagine you'd post a followup comment like:

@alice: I wanted to start work on this but it looks like I don't have access to T456, can you give me access or summarize the relevant piece so I can make sure I'm not missing anything?

At least in this case, I think it doesn't really matter what the actual access policy of T456 is, and Alice is probably the best person to satisfy the access request (since she understands the context of the request and the relevance of the task, and has the most information of anyone to help her make a decision about how to move forward).

If you just wake up in the morning and, say, access every new task in order (T234000, T234001, T234002, etc.) purely out of curiosity or whatever, this doesn't help, but I think that's rare? Are you running across objects in some way that doesn't provide an obvious "someone" in context?

This is referenced upstream by https://secure.phabricator.com/T13411 and "resolved" upstream by https://secure.phabricator.com/D20806.

This change does not do what this task originally asked for (provide more information about custom policies for objects you do not have permission to see when you encounter a policy exception). Instead, it does the opposite and removes policy information about objects you can't see (notably, it removes the name of the project for objects which have a policy like "Visible To: Members of Project X").

The old behavior was to show the users who can not see the object:

Members of project "Security" can take this action.

The new behavior shows this to these users instead:

Members of a particular project can take this action. (You can not see this object, so the name of this project is restricted.)

For users who can see the object, the behavior is unchanged (it still shows the project name).

The behavior for custom policies when you can not see objects is also unchanged: you will still receive a summary message ("This object has a custom policy controlling who can take this action.") with no details about the policy rules.

This may or may not be satisfactory, but the behavior is now more consistent, and I don't currently plan to make upstream changes to disclose object policy rules to users who can't see objects. Broadly, although there's a lot of grey area and room for subjectivity here, I think this discloses too much information about object content in many reasonable cases.

See also T211498 for an adjacent change which provides more detail on custom policies to users who can see the object.