So, with regards to db_owner. Or organization refuses db_owner permission for production machines and only allows specific read/write. Is there any point where we can remove this db_owner permission on the account? If not, please explain.
I don’t perceive much risk as the system is designed, but any technical safeguards that SonarSource has put into place which makes this feasibly low-risk, please convey this, as well.
The documentation has specified db_owner for years… and for 5 years I’ve been asking the question “Why?” and nobody has provided me with an answer.
I have a feeling (I don’t know for sure) that this is leftover from older days of SonarQube. The tickets I can find that reference db_owner are all from v3.x and v4.x of SonarQube.
While we fixed these issues in the code (a very different-looking codebase than today, the code fixed was even written in Ruby, not Java!), it might have been decided to document the requirement just to avoid having those issues in the future. It’s long ago enough that frankly, nobody still active on the codebase remembers.
It’s 2023 – and I know our team of Support Engineers regularly sets up SonarQube on Microsoft SQL Server without db_owner permissions without issue. Specifically, they grant db_datawriterdb_datareader and db_ddladmin. This has also been recommended to some customers.
I think you can safely do the same. In any case, I’ll tag this thread for attention from some experts and maybe we can stop documenting it