dmeyer, Why is this closed as "won't fix" when there seems to be a duplicate that is "In progress" (JRACLOUD-75053)?

Also, "interestingly" enough, JRACLOUD-75053 is in progress, but does not have any assignee. 

Hello Guys!

We have same problem here. 
It's critical security breach, and we need some update about that.
Can you guys open again this feature?!

According to this comment from the server equivalent of this bug belive this bug needs to be reopened and addressed. 

If the same apply to cloud (that achieved projects using this feature can be exposed) you we have an more severe issue. 

And the status update is just scary. What You are basically stating is "We wont address security issues that are complex to fix". Seriously??? 

Please reopen and add the "security" label to this issue.

Hi everyone,

We have reviewed the status of this issue and there are not currently plans to fix this bug in Jira Cloud. Extensive analysis over the last couple years has indicated that the complexity of addressing this bug without causing performance degradation for customers using permission schemes with user custom field grants is significant. Based on the number of customers that have actually been affected, we cannot justify the effort required to address it at this time.

Thanks for your understanding.

Regards,
Dave Meyer
Senior Product Manager, Jira Cloud

Any news on this?

The bug is now 3 years old and a year ago you wrote, that you are working on a solution...

Please deploy!

Hi nwheaton1,

We have reconsidered the above and currently have in the short-term backlog to work on implementing that solution. Please watch this issue and related tickets for further updates

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

This bug sounds like a real security problem. Now I will have to audit all of our permission schemes to ensure that no custom fields are listed under BROWSE_PROJECT.

> We attempted to explore a more thorough fix, by separating the current BROWSE permission into two separate BROWSE_PROJECT (acts upon the project) / VIEW_ISSUE (acts on particular issues) permissions in the permission scheme, but concerns upon the UX impact of adding yet another value to configure in the permission scheme held back work on this.

This sounds like a reasonable workaround given the severity of this security issue.

Reproduced in v6.4.12.
Please fix it.

This is a big issue for us as well. Please fix it.

I also run into this problem. Please fix it.

Please provide your steps so we can test it.

Managed to find workaround using security levels.

There are a whole bunch of bug reports relating to this and the first one I can see started in Feb 2013. It's now been 2 years. Atlassian has a reputation for not bothering to fix bugs which don't match their own internal use cases. There are simple enough solutions suggested by various people but they are just not interested. Sadly, I don't know what will make them take action on this bug, except perhaps a competitor taking enough of their market share to make them take notice.

Is there any workaround for fixing that issue, except multiple jira instances? I tried to google it but haven't find any.

The use case scenario is - we have a lot of different products (projects) and generally the outside reporters shouldn't see bugs by other reporters but sometimes they should, so they invite other people from their group using custom field "invite other users". but it leads to seeing all the projects. so for today the only solution is to start multiple instances of jira, which is confusing.

are there any plans to fix that issue?

thanks forward

I don't see how the separation into two separate permissions would solve the performance issue associated with https://jira.atlassian.com/browse/JRA-36699 . Most likely what is happening is that to evaluate whether a user can view the existence of a project, the full list of issues in that project needs to be iterated to check whether the user is listed in any of the issues user custom field values. Therefore to determine visibility of a project will take O ( n ) time, which is unacceptable. In order to achieve a fixed time regardless of the number of issues O ( 1 ), I suggest the following solution:

Have a register (or a cache) of project permissions stored in association with each user. When an issue is updated, check the permissions scheme to see if any user custom field values in the issue are referenced by it. If so, update the users project permissions register.

Then, when evaluating whether a user has browse project permission for a particular project, just check the users permissions register for that project.

Core problem: ability for an unrelated user to view all projects even when they are company internal and restricted.

1. Log in as an administrator into JIRA
2. Go to Administration > Custom Fields
3. Create a new custom User Lookup Field called "Additional Users", using the field type "User Picker (multiple users)". This can be found in the "advanced" set of field types.
4. On the next page associate the new field with the "Create Issue" screen.
5. Create a new, empty permissions scheme called "Test Permission Scheme"
6. Create a new project called "Test Permissions Project"
7. Assign the permissions scheme "Test Permission Scheme" to the project "Test Permissions Project"
8. Create a new user account called "jira.testuser"
9. Logout and login to the user account "jira.testuser". You will see that in the top bar of jira there is no "Projects" menu item. This is the correct behaviour
10. In your browser go to the JIRA url /secure/BrowseProjects.jspa#all and you will see the message "You do not have the permissions required to browse any projects. To change your permissions, please contact your JIRA administrators.". This is the correct behaviour.
11. Logout and log in as an administrator again.
12. Open and edit the permissions scheme "Test Permission Scheme"
13. For the permission "Browse Projects", click the "Add" operation link
14. Select the "User Custom Field Value" radio button and in the associated drop list, select the "Additional Users" field, then Click the "Add" button at the bottom of the screen.
15. Log out and log in to the user account "jira.testuser". You will see that in the top bar of jira there is a "Projects" menu item. This is incorrect behaviour as the user has not been given access to anything, nor has the user account been associated with any JIRA project or issue.
16. In the projects menu item, click on "View All Projects" or navigate directly to the url /secure/BrowseProjects.jspa#all. You will see the "Test Permissions Project" listed. This is incorrect behaviour as the user has not been given access to anything, nor has the user account been associated with any JIRA project or issue.

Atlassian suggested workaround: Issue level security.

Prerequisites: The first set of steps that creates the project "Test Permissions Project" and an associated security scheme.

1. Log in as an administrator into JIRA
2. Open and edit the permissions scheme "Test Permission Scheme"
3. For the permission "Browse Projects", in the right hand column click "Delete" on any "User Custom Field Value" permissions, and confirm their deletion.
4. Go to Administration > Issue Security Schemes
5. Click "Add Issue Security Scheme", and set the name of the scheme to "Test Permissions Issue Security Scheme". Click "Add".
6. On the "Test Permissions Issue Security Scheme" click on the operation "Security Levels"
7. Under "Add Security Level", enter "All Project Roles And Additional Users" in the Name field, and click "Add Security Level"
8. On the security level "All Project Roles And Additional Users", click the "Default" operation.
9. On the security level "All Project Roles And Additional Users", click the "Add" operation.
10. Select the "Project Role" radio button, and select the first project role from the list.
11. Repeat steps 9 and 10, adding the rest of the project roles in the list.
12. On the security level "All Project Roles And Additional Users", click the "Add" operation.
13. Select the "User Custom Field Value" radio button, and select "Additional Users" from the drop list.
14. Go to Administration > Projects and click on the "Test Permissions Project" to open it.
15. Under "Permissions", where it says "Issues: None" click on the link for "None" and change it use the "Test Permissions Issue Security Scheme"
16. On step 2, choose the "All Project Roles And Additional Users" security level to apply to all issues.
17. Under the project "Test Permissions Project", create a new issue. When filling out the issue fields, enter "jira.testuser" into the field "Additional Users".
18. Navigate to the issue and copy the URL to your operating system clipboard.
19. Logout and login to the user account "jira.testuser".
20. Paste the URL of the issue you created as administrator into the web browser address bar for the currently logged in user (jira.testuser).
21. You will be presented with a page titled "Permission Violation". This proves that issue level security is only an additional restriction on project level permissions, and without the "Browse Projects" permission, a user cannot view any issues within that project, regardless of any Issue Level Security settings.

Attempted workaround: https://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission

The following set of steps can be applied to either of the two additional permissions that can be uncommented in
Installation Folder/atlassian-jira/WEB-INF/classes/permission-types.xml, however for this set of steps we have chosen to use the "assignee assignable" permission.

1. Log in as an administrator into JIRA
2. Under the project "Test Permissions Project", open the issue you created in the last set of steps. Edit the issue and remove any value for the field "Additional Users".
3. Open the file Installation Folder/atlassian-jira/WEB-INF/classes/permission-types.xml and uncomment the additional permission with id "assigneeassignable"
4. Restart JIRA
5. Log in as an administrator into JIRA
6. Open and edit the permissions scheme "Test Permission Scheme"
7. For the permission "Assignable User", click the "Add" operation link
8. Select the "User Custom Field Value" radio button and in the associated drop list, select the "Additional Users" field, then click the "Add" button at the bottom of the screen.
9. For the permission "Browse Projects", click the "Add" operation link
10. Select the radio button "Assignee (show only projects with assignable permission)", then click the "Add" button at the bottom of the screen.
11. Log out and log in to the user account "jira.testuser". You will see that in the top bar of jira there is a "Projects" menu item. This is incorrect behaviour as the user has not been given access to anything, nor is the user currently associated with any JIRA project or issue.
12. In the projects menu item, click on "View All Projects" or navigate directly to the url /secure/BrowseProjects.jspa#all. You will see the "Test Permissions Project" listed. This is incorrect behaviour as the user has not been given access to anything, nor has the user account been associated with any JIRA project or issue.

All of the possible workarounds do not work. The core issue cannot be fixed by a workaround. This bug must be fixed by the JIRA developers.

ohernandez, I can't speak for Jon but in my case, I have external users whom I have blocked from all except one project (project x). In another project (project y), the permission scheme is quite restrictive but allows for any user in a User Custom Field Value to be able to browse the project.

In the way the bug states, this makes project y visible to the external users. The issues in the project are not browsable, just headings and components. It was explained by another user in the comments of a different issue which I can't recall at the moment, but there are often security implications with even simple heading and titles being visible to external users when they involve secret projects or other sensitive information.

Thanks for catching that jonathan.sword, it has indeed not been fixed.

The initial attempt at fixing this caused a major performance regression (JRA-36699), so we had to revert to the original behaviour.

We attempted to explore a more thorough fix, by separating the current BROWSE permission into two separate BROWSE_PROJECT (acts upon the project) / VIEW_ISSUE (acts on particular issues) permissions in the permission scheme, but concerns upon the UX impact of adding yet another value to configure in the permission scheme held back work on this.

It would would be useful to understand what is your case to restrict access to the Project pages for specific users, could you please share that with us?

Many thanks in advance.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

This issue is open, but it's fix version is 6.1.6?