Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • gitlab-runner gitlab-runner
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 972
    • Issues 972
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Jira
    • Jira
  • Merge requests 88
    • Merge requests 88
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar

Do not update/delete: Banner broadcast message test data

Do not update/delete: Notification broadcast message test data

  • GitLab.orgGitLab.org
  • gitlab-runnergitlab-runner
  • Issues
  • #1736
Closed
Open
Issue created Sep 28, 2016 by username-removed-164769@fresskoma

File/directory creation umask when cloning appears to be `0000`?

I'm assuming that this is not a bug, but maybe someone can tell me the rationale behind this decision.

We're currently re-building our continuous delivery setup on GitLab/Gitlab CI and noticed that file permissions are odd when deploying through Gitlab CI. When gitlab-ci-multi-runner checks out a repository inside a docker container, it appears to be doing so with umask 0000, with the result that everything that's checked out is world-writable. This is not a problem inside the container, but since we deploy from inside the container, the permissions are also transferred to the production system.

It seems like this behavior cannot be influenced, since before_script runs after the repository has been cloned. To verify that my assumption about the umask was correct, I threw in a w.Command("umask", "0022") in abstract.go L61, which resulted in the correct (for me) file permissions being set.

So my questions are:

  1. Is this intended behavior, and if so, what is the rationale?
  2. Can this be influenced in any way?
    • If it is not, I'd be willing to submit a merge request providing such functionality after discussing what the best approach would be to do so

Thanks for your time :)

Assignee
Assign to
Time tracking