Try running it from the command line with
sudo gnome-builder
This should give the same effect as if the app were calling sudo on everything. Best of all, it is temporary, as elevated privileges generally should be.
EDIT:
Sunday, I decided to keep this answer short, as it is simple answer. Judging by the down-vote, however, someone didn't think so, so I will add more context and related info in the name of making it a robust. I am not sure how you came to the conclusion that sudo is the issue (it would be a good idea to update your question with this info, as it is useful context for anyone answering), but if starting the app with sudo returns anything other than 0, then your conclusion was wrong. If it won't start as root, then either:
1.) It doesn't need root permissions. Make does not need sudo unless you are running make install and the binaries (/bin), libraries (/lib), etc. (pun intended) are going going into the system directories (as opposed to the sym-linked user directory.) The GNU standard is to install most stuff there anyway, as the alternative will likely cause confusion / errors with version mismatches and similar issues on a multi-user system.
...or else:
2.) You installed it with Flatpak. If this is, by chance, the case, you will need an entirely different answer. When it comes to app security, Flatpak doesn't mess around. When it comes to giving Flatpak the permissions they need, you might as well be trying to give root access to your Android app.
Well, it isn't quite that bad, but it isn't good either. On flatpak, it is possible. That is where the differences end. They use sandboxing, like Snap. Snap, however, gives us the --classic option, which must be added when it is first downloaded, and bypasses the sandboxing feature altogether. Flatpak does not have anything similar to this.
If you installed the flatpak, read this.
While doing research on the --classic info above, I ran across an EXCELLENT post on the subject of sandboxed Package Managers. Both the question and the answers (especially the first one) were impressive. The latter had this to say about the sandboxing implimentations from the main three package managers that use this architecture:
Sandboxing / Confinement
| Feature |
AppImage |
Snap |
Flatpak |
| Can run without sandboxing |
✅ Yes (Not required. Optional to the packager.) |
✅ Yes (if snap was built and approved to use 'classic' confinement) [1] [2] |
:x: No (Limiting application access's by design) |
| Can be used with different sandboxes |
✅ Yes (e.g. Firejail [1], AppArmor [2], Bubblewrap) |
:x: No (is tightly coupled to AppArmor) |
:x: No (is tightly coupled to Bubblewrap) |
NOTE:
Neither the table nor anything contained therein is my work. I found it in an answer given by @KurtPfeifle, to a question by @LuisAlvarado. Both were filled with great content. Thanks to both of you for excellent contributions.
