Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-24987

[Regression] Default permission when archiving a build

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Jenkins v1.582 / Debian 7

      Hi,

      It seems that there a regression with a recent patch.
      Whem i'm building my application, and archiving it in order to deploy the application, the default permission seems to have changed in *a bad way*.

      You can see the screenshot attached that the v1.0.6 has "normal" permission but after a jenkins update, the version 1.0.8 on the screenshot have really weird permissions which prevent the webserver from reading the content of the folder.
      (i had to manually set the correct permissions for 1.0.9)

      I didn't touch the build script responsible of building the archive or the deployment method between those versions.

      I suspect the umask PR thing to be the cause (but this is just a guess) : https://github.com/jenkinsci/jenkins/pull/1397

          [JENKINS-24987] [Regression] Default permission when archiving a build

          Daniel Beck added a comment -

          Why are you reporting a bug (Blocker even) instead of just changing the setting you're obviously aware of?

          Daniel Beck added a comment - Why are you reporting a bug (Blocker even) instead of just changing the setting you're obviously aware of?

          tristan bessoussa added a comment - - edited

          Because this bug prevent me from deploying without human interaction.
          And which setting are you referring to ? If I was aware of a solution I wouldn't bother you in here. Just trying to help by providing the more detail I can.

          tristan bessoussa added a comment - - edited Because this bug prevent me from deploying without human interaction. And which setting are you referring to ? If I was aware of a solution I wouldn't bother you in here. Just trying to help by providing the more detail I can.

          Daniel Beck added a comment -

          You found https://github.com/jenkinsci/jenkins/pull/1397
          which includes the line (second commit): only set umask if set in /etc/default/jenkins
          referencing https://github.com/jenkinsci/jenkins/blob/master/debian/debian/jenkins.default#L45

          So it seemed obvious you knew about this option.

          It's also noted in the change log at http://jenkins-ci.org/changelog#v1.579

          Does the presence of this option resolve this issue for you?

          Daniel Beck added a comment - You found https://github.com/jenkinsci/jenkins/pull/1397 which includes the line (second commit): only set umask if set in /etc/default/jenkins referencing https://github.com/jenkinsci/jenkins/blob/master/debian/debian/jenkins.default#L45 So it seemed obvious you knew about this option. It's also noted in the change log at http://jenkins-ci.org/changelog#v1.579 Does the presence of this option resolve this issue for you?

          tristan bessoussa added a comment - - edited

          I wasn't excepting a BC break on a minor update, but my bad on this.
          Unfortunatly,
          1) I commented the umask in `/etc/default/jenkins` as advised
          2) I restarted jenkins `service jenkins restart`
          3) I rebuilt the release of v1.0.9 of my application.

          The result is the same after extract:,
          `drwxr-x--- 12 jenkins jenkins 4096 Oct 1 18:08 v1.0.9`

          I tried this again and before launching the build, I ereased all previous v1.0.9 archieved builds. The result is the same.

          Does umask need to be set at a particular version to restore original settings ? Or do I need to reset my whole workspace so it can git clone with correct file/folder permission ? (The date still refer to the first time I built this tag)

          Thanks for your help .

          tristan bessoussa added a comment - - edited I wasn't excepting a BC break on a minor update, but my bad on this. Unfortunatly, 1) I commented the umask in `/etc/default/jenkins` as advised 2) I restarted jenkins `service jenkins restart` 3) I rebuilt the release of v1.0.9 of my application. The result is the same after extract:, `drwxr-x--- 12 jenkins jenkins 4096 Oct 1 18:08 v1.0.9` I tried this again and before launching the build, I ereased all previous v1.0.9 archieved builds. The result is the same. Does umask need to be set at a particular version to restore original settings ? Or do I need to reset my whole workspace so it can git clone with correct file/folder permission ? (The date still refer to the first time I built this tag) Thanks for your help .

          Daniel Beck added a comment -

          I'm a bit surprised it didn't work. Add diagnostic output to make sure your umask setting is correct.

          Try creating a new job that only touches a file on the master node. What are the permissions?

          Try service stop/start instead of restart. Probably useless, but who knows.

          Try changing the jenkins init script to completely remove --umask argument.

          Daniel Beck added a comment - I'm a bit surprised it didn't work. Add diagnostic output to make sure your umask setting is correct. Try creating a new job that only touches a file on the master node. What are the permissions? Try service stop/start instead of restart. Probably useless, but who knows. Try changing the jenkins init script to completely remove --umask argument.

          Daniel Beck added a comment -

          Not a blocker.

          Daniel Beck added a comment - Not a blocker.

          tristan bessoussa added a comment - - edited

          Ok so,

          1) Stop then Restart jenkins has no effect (compared to restart)

          I went to the job, deleted the build and the corresponding artifact
          Commented out the umask in the init.d script
          I stopped/started jenkins
          Started the job again
          Unzip the archive
          Works again.

          Thanks.

          tristan bessoussa added a comment - - edited Ok so, 1) Stop then Restart jenkins has no effect (compared to restart) I went to the job, deleted the build and the corresponding artifact Commented out the umask in the init.d script I stopped/started jenkins Started the job again Unzip the archive Works again. Thanks.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          debian/debian/jenkins.default
          http://jenkins-ci.org/commit/jenkins/9c96f3dcca1784094f28ccd6df6abed1d229a1d4
          Log:
          [FIXED JENKINS-25065 JENKINS-24987]

          Based on the reaction to these issues and JENKINS-24514, I'm partially
          reverting the original change, and bringing the umask default back to
          022.

          The configurable option does enable the user to choose a different
          umask, so I think I can still claim that JENKINS-24514 is addressed.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html debian/debian/jenkins.default http://jenkins-ci.org/commit/jenkins/9c96f3dcca1784094f28ccd6df6abed1d229a1d4 Log: [FIXED JENKINS-25065 JENKINS-24987] Based on the reaction to these issues and JENKINS-24514 , I'm partially reverting the original change, and bringing the umask default back to 022. The configurable option does enable the user to choose a different umask, so I think I can still claim that JENKINS-24514 is addressed.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3730
          [FIXED JENKINS-25065 JENKINS-24987] (Revision 9c96f3dcca1784094f28ccd6df6abed1d229a1d4)

          Result = SUCCESS
          kohsuke : 9c96f3dcca1784094f28ccd6df6abed1d229a1d4
          Files :

          • changelog.html
          • debian/debian/jenkins.default

          dogfood added a comment - Integrated in jenkins_main_trunk #3730 [FIXED JENKINS-25065 JENKINS-24987] (Revision 9c96f3dcca1784094f28ccd6df6abed1d229a1d4) Result = SUCCESS kohsuke : 9c96f3dcca1784094f28ccd6df6abed1d229a1d4 Files : changelog.html debian/debian/jenkins.default

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/jenkins.default
          http://jenkins-ci.org/commit/packaging/9e97bed31ebd389bbca6889f8328c0b5725f26fc
          Log:
          [FIXED JENKINS-25065 JENKINS-24987]

          Based on the reaction to these issues and JENKINS-24514, I'm partially
          reverting the original change, and bringing the umask default back to
          022.

          The configurable option does enable the user to choose a different
          umask, so I think I can still claim that JENKINS-24514 is addressed.

          Originally-From: jenkins-ci.org/commit/core/9c96f3dcca1784094f28ccd6df6abed1d229a1d4

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/jenkins.default http://jenkins-ci.org/commit/packaging/9e97bed31ebd389bbca6889f8328c0b5725f26fc Log: [FIXED JENKINS-25065 JENKINS-24987] Based on the reaction to these issues and JENKINS-24514 , I'm partially reverting the original change, and bringing the umask default back to 022. The configurable option does enable the user to choose a different umask, so I think I can still claim that JENKINS-24514 is addressed. Originally-From: jenkins-ci.org/commit/core/9c96f3dcca1784094f28ccd6df6abed1d229a1d4

            kohsuke Kohsuke Kawaguchi
            sf_tristanb tristan bessoussa
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: