-
Suggestion
-
Resolution: Unresolved
-
None
-
49
-
Problem Definition
It's easy for project Admins to make a mistake and not realize the implications of enabling the Project Default Permissions feature.
Suggested Solution
- A save button with a warning message
- A property that can disable the feature
Workaround
Develop a third party plugin that removes the feature.
- is duplicated by
-
- Gathering Interest
- relates to
-
- Gathering Interest
-
- Gathering Interest
[BSERV-10028] Ability to remove Project Default Permission
Definitely should be a switch that removes the project admin ability to control default access,
this can bypass all permissions managed by groups and cause a major permissions issue.
After we upgrade to Bitbucket DC 8.x , permission-lockdown-for-bitbucket-server do not work.
Have any other way can disable the default permission feature in project?
This is a big security hole, please fix this. Provide us with the ability to disable default read and default write.
I agree with you. My opinion is that: either this plugin is provided open source so that "community" can maintain and review it, either it is embedded in product and becomes supported.
My security team wants to be able to limit user access directly to projects that they have a need to access to minimize the potential for a compromised account to access a wide amount of source code. This default feature which can be set to allow users to access a project or repo just by being logged in without directly having permissions allocated to them is something that I cannot allow to be enabled.
This should be a simple feature to provide in the core product as the Permission Lockdown plugin under Atlassian Labs https://marketplace.atlassian.com/apps/1217941/permission-lockdown-for-bitbucket-server provides exactly this feature. I would think that a plugin built by an Atlassian developer would already be IP that Atlassian owns based on employee agreements. So the feature just needs to be integrated into the product. The concern in using the plugin is only in that it is listed as unsupported and the need for it that I have is a critical security requirement; so knowing it will continue to be available for future versions is a big deal for my use case.
Please consider this need for the use case I mention. I can't image that my security team is unique in the limits they want to have configured.
vic1953362978 to address your, and your customer's, specific request for dates and implication that changes are trivial, I'd like to set clear expectations.
As you can probably appreciate, a mature product like Bitbucket has hundreds of suggestions for improvement. Each is prioritised and worked based on a number of factors, and unfortunately the appearance of a change being small is only a small factor. The prioritisation we do optimises for the value features provide to customers. While this suggestion has merit, it has low reach (affects few people), low frequency, and I'd guess moderate impact.
If you would like to know more about how Atlassian Product Management uses customer input during the planning process, please see this post on Atlassian Answers and our new features policy.
100% needed functionality