-
Bug
-
Resolution: Won't Fix
-
Medium
-
18
-
Severity 2 - Major
-
NOTE: This bug report is for JIRA Cloud. Using JIRA Server? See the corresponding bug report.
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
If in your permission schema, you grant Browse Project permission to "User Custom Field Value", the project is visible to all users. Regardless of whether that field is filled or not.
JRA-31720 fixed that for the current assignee - i had hoped this would work for custom fields too.
- is cloned from
-
-
- Closed
-
- was cloned as
-
JRACLOUD-75053 Grant "Browse Project" permission to "User Custom Field Value" makes project visible to all users
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRACLOUD-37117] Grant "Browse Project" permission to "User Custom Field Value" makes project visible to all users
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...
Steve Kostrey
added a comment - 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].
NeilW
added a comment - 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.
NeilW
added a comment - 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.
Its really depressing that You choose not to fix a security bug, where users un-intentionally via the nomal (out of the box) interface can create a mis-configuration that makes a project visible to all users. I do think that is a violation of "Dont F*ck the customer"....
And stating "Based on the number of customers that have actually been affected, " - its that countlable, or are you basing this on the number of bug reports from users that are aware of the problem...