Parent directory permissions are not reset by reconfigure when "gitlab_rails['shared_path']" set
Summary
It is expected that gitlab-ctl reconfigure
will reset any modified permissions on folders that it created when first run, including parent folders of configured locations. This does not happen when gitlab_rails['shared_path']
is set to a non-default location and if permissions have been removed from the parent folder.
This issue arose from a customer ticket (ZD internal link) where permissions on an intermediate folder were somehow changed (perhaps during migration activity) causing the registry to be unable to access its image files. The permissions were reset manually but the question was raised as to why gitlab-ctl reconfigure
didn't reset them to their original correct values.
I appreciate that this is an edge case and the result of changes made to folder permissions outside of GitLab, but the expectation that a reconfigure should "fix" things it originally created seems reasonable.
Steps to reproduce
- Deploy a new install of GitLab with
gitlab_rails['shared_path'] = '/base/nfs/gitlab-np/gitlab-data/shared'
- The intermediate
/base/nfs/gitlab-np/gitlab-data
is created with permissionsdrwxr-xr-x 3 root root 4096 Dec 21 02:50 gitlab-data
- Change the permissions via
chmod o-rx /base/nfs/gitlab-np/gitlab-data
- Rerun reconfigure - an error is observed:
storage_directory[/base/nfs/gitlab-np/gitlab-data/shared] (gitlab::rails_pages_shared_path line 5) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[directory resource: /base/nfs/gitlab-np/gitlab-data/shared] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb line 34) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of stat --printf='%U' $(readlink -f /base/nfs/gitlab-np/gitlab-data/shared) ----
STDOUT:
STDERR: stat: missing operand
Try 'stat --help' for more information.
---- End output of stat --printf='%U' $(readlink -f /base/nfs/gitlab-np/gitlab-data/shared) ----
Ran stat --printf='%U' $(readlink -f /base/nfs/gitlab-np/gitlab-data/shared) returned 1
- Change the ownership of
/base/nfs/gitlab-np/gitlab-data
to match the settings applied to the default location:chown git:root /base/nfs/gitlab-np/gitlab-data
- Rerun reconfigure - no error this time but the permissions on
/base/nfs/gitlab-np/gitlab-data
remain unchanged.
This behavior is not observed when the default locations are used and the /var/opt/gitlab/gitlab-rails
folder permissions are changed, presumably because this location is handled separately via the #gitlab_rails['dir'] = "/var/opt/gitlab/gitlab-rails"
setting.
What is the current bug behavior?
gitlab-ctl reconfigure
does not reset the permissions of all folders initially created by reconfigure to their required values.
Also, reconfigure errors when permissions on parent folders are such that the git user can't access the configured shared folder, despite it having root access.
What is the expected correct behavior?
gitlab-ctl reconfigure
should reset the permissions to their original values, and should not error when permissions prevent folder access by the git user.