Unified Backups: Allow restoring from a backup with `gitlab-backup-cli`

Summary

The Unified Backup CLI: gitlab-backup-cli needs additional permissions to run a system-wide backup. Our initial implementation tried to run as root user, but since we haven't fully decoupled from the rails codebase, we need to run with reduced privileges.

We discussed internally and we thought running with a separate user would make sense, even if we had fully decoupled from rails.

During the attempt to run it as the $gitlab_user (git): !7598 we found out that restoring from a backup doesn't work correctly as not all data is owned by that same user.

Proposal

Make the following changes managed by omnibus:

1. Create a new user: gitlab-backup.
2. Change git group to include gitlab-backup
3. Change registry group to include gitlab-backup
4. Change gitlab-www group to include gitlab-backup
5. Change each data-folder in the shared path to allow the group to have the same permissions
6. Set g+s (group stick permission) to each of the data-folders in the shared path
7. Ensure https://docs.gitlab.com/omnibus/settings/configuration.html#disable-user-and-group-account-management is updated to include information about the new user

This will allow us to modify !7598 to use the gitlab-backup user instead git

By running with a user that has group permission to each data-folder we can safely restore data in each of them, and restore their previous ownership after unpacking the backups. Group ownership is preserved by the groups stick permission

Additional considerations

From @deriamis (!7598 (comment 1912778477))

Based on my prior experience, that seems like the right way forward. Please make sure the addition of a new user during upgrade (and the associated permissions changes) is documented and communicated forward very clearly because it represents an increase in security risk for our customers, and some of them may have tooling that needs to be altered to monitor/allow the change.

We should also take the stance that anything stored in shared is inherently untrusted, so restores should be done carefully. We should make sure we don't, for instance, restore stored procedures automatically nor restore symlinks that reach outside of where we expect them to. I know we don't create any of the above via our processes, but consider a customer who might be restoring data after having their instance compromised. Also, make "eventually" in the "restore correct user ownership" part of the definition of done because that's another potential security problem.

References

Original discussion on Slack: https://gitlab.slack.com/archives/C1FCTU4BE/p1715866795366699

Additional comments where made here: !7598 (comment 1912778477)