• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • OS: RHEL 6
      Jenkins: 2.93
      ThinBackup: 1.9

      After upgrading to Jenkins 2.93, ThinBackup sets the permissions of installedPlugins.xml to 600.  Previously, the permission were 644, matching the original file.

      If I watch the permissions as a backup is running, the permissions start as 644, but change to 600 by the time the backup completes.

      The dnusbaum user on IRC recommended I create this issue. 

      EDIT: This issue was discovered when automation attempts to copy the backups files off of the server as non jenkins user. I assume since the permissions of the backups are different than JENKINS_HOME, that restoring would fail. I have not had a chance to test this theory.

          [JENKINS-48407] Permission issue after upgrade to 2.93

          b harper created issue -
          Devin Nusbaum made changes -
          Link New: This issue relates to JENKINS-36088 [ JENKINS-36088 ]

          Devin Nusbaum added a comment -

          Thanks for creating the ticket. Can you confirm whether you mean that the permissions of installedPlugins.xml are incorrect in the file that is in the backup archive, or that the permissions of installedPlugins.xml in JENKINS_HOME is changing?

          There is a chance that the chmod/mode changes as part of JENKINS-36088 could be causing this, but you said that setting hudson.util.useNativeChmodAndMode=true had no effect? It looks like thinbackup-plugin uses the java.util.zip API, which does not preserve file permissions or use chmod/mode, so I don't think the changes in 2.93 would affect this. We could potentially modify the plugin to use ZipArchiver so that it would preserve permissions, but that doesn't explain why this is a problem now.

          Are you unzipping the backup somewhere other than when it was working before you upgraded to 2.93? umask settings should affect permissions on the unzipped archive.

          Devin Nusbaum added a comment - Thanks for creating the ticket. Can you confirm whether you mean that the permissions of installedPlugins.xml are incorrect in the file that is in the backup archive, or that the permissions of installedPlugins.xml in JENKINS_HOME is changing? There is a chance that the chmod/mode changes as part of JENKINS-36088 could be causing this, but you said that setting hudson.util.useNativeChmodAndMode=true had no effect? It looks like thinbackup-plugin uses the java.util.zip API, which does not preserve file permissions or use chmod/mode, so I don't think the changes in 2.93 would affect this. We could potentially modify the plugin to use ZipArchiver so that it would preserve permissions, but that doesn't explain why this is a problem now. Are you unzipping the backup somewhere other than when it was working before you upgraded to 2.93? umask settings should affect permissions on the unzipped archive.

          Devin Nusbaum added a comment -

          Also I'm no expert on thinbackup, so I might be wrong about it's use of zip archives. Still looking to see exactly how it works.

          Devin Nusbaum added a comment - Also I'm no expert on thinbackup, so I might be wrong about it's use of zip archives. Still looking to see exactly how it works.

          b harper added a comment - - edited
          Can you confirm whether you mean that the permissions of installedPlugins.xml are incorrect in the file that is in the backup archive, or that the permissions of installedPlugins.xml in JENKINS_HOME is changing?

          Sorry for the confusion. The permissions in JENKINS_HOME are not effected, but are effected within the Backup directory.

          Are you unzipping the backup somewhere other than when it was working before you upgraded to 2.93?

          I am not using the zip feature and just keeping the backups as flat files.

          b harper added a comment - - edited Can you confirm whether you mean that the permissions of installedPlugins.xml are incorrect in the file that is in the backup archive, or that the permissions of installedPlugins.xml in JENKINS_HOME is changing? Sorry for the confusion. The permissions in JENKINS_HOME are not effected, but are effected within the Backup directory. Are you unzipping the backup somewhere other than when it was working before you upgraded to 2.93? I am not using the zip feature and just keeping the backups as flat files.

          Devin Nusbaum added a comment -

          Ok, thanks for the clarification. I'll try to reproduce this with 2.92 and 2.93.

          Devin Nusbaum added a comment - Ok, thanks for the clarification. I'll try to reproduce this with 2.92 and 2.93.

          b harper added a comment -

          I forgot to mention, I upgraded from 2.88 to 2.93.

          b harper added a comment - I forgot to mention, I upgraded from 2.88 to 2.93.

          Devin Nusbaum added a comment -

          I was able to reproduce the problem with 2.88 and 2.93. Notably, it is specific to installedPlugins.xml, other files still have 644 permissions.

          Devin Nusbaum added a comment - I was able to reproduce the problem with 2.88 and 2.93. Notably, it is specific to installedPlugins.xml , other files still have 644 permissions.

          Devin Nusbaum added a comment - - edited

          I reverted the chmod/mode changes and tested, but the problem was still present.

          I think this is related to the AtomicFileWriter changes in PR #2548. Here is a fresh JENKINS_HOME from 2.93:

          total 64
          -rw-------   1 dnusbaum  staff   1.7K Dec  6 14:59 config.xml
          -rw-r--r--   1 dnusbaum  staff    29B Dec  6 14:59 failed-boot-attempts.txt
          -rw-------   1 dnusbaum  staff   156B Dec  6 14:59 hudson.model.UpdateCenter.xml
          -rw-------   1 dnusbaum  staff   1.7K Dec  6 14:59 identity.key.enc
          -rw-------   1 dnusbaum  staff    94B Dec  6 14:59 jenkins.CLI.xml
          -rw-r--r--   1 dnusbaum  staff     4B Dec  6 14:59 jenkins.install.UpgradeWizard.state
          drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 14:59 jobs/
          drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 14:59 logs/
          -rw-------   1 dnusbaum  staff   907B Dec  6 14:59 nodeMonitors.xml
          drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 14:59 nodes/
          drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 14:59 plugins/
          -rw-------   1 dnusbaum  staff    64B Dec  6 14:59 secret.key
          -rw-r--r--   1 dnusbaum  staff     0B Dec  6 14:59 secret.key.not-so-secret
          drwx------  11 dnusbaum  staff   374B Dec  6 14:59 secrets/
          drwxr-xr-x   4 dnusbaum  staff   136B Dec  6 14:59 updates/
          drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 14:59 userContent/
          drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 14:59 users/
          drwxr-xr-x  25 dnusbaum  staff   850B Dec  6 14:59 war/

          If I revert the merge of PR #2548, a fresh JENKINS_HOME looks like:

          -rw-r--r--   1 dnusbaum  staff   1.7K Dec  6 15:12 config.xml
          -rw-r--r--   1 dnusbaum  staff   156B Dec  6 15:12 hudson.model.UpdateCenter.xml
          -rw-------   1 dnusbaum  staff   1.7K Dec  6 15:12 identity.key.enc
          -rw-r--r--   1 dnusbaum  staff    94B Dec  6 15:12 jenkins.CLI.xml
          -rw-r--r--   1 dnusbaum  staff     4B Dec  6 15:12 jenkins.install.UpgradeWizard.state
          drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 15:12 jobs/
          drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 15:12 logs/
          -rw-r--r--   1 dnusbaum  staff   907B Dec  6 15:12 nodeMonitors.xml
          drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 15:12 nodes/
          drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 15:12 plugins/
          -rw-r--r--   1 dnusbaum  staff    64B Dec  6 15:12 secret.key
          -rw-r--r--   1 dnusbaum  staff     0B Dec  6 15:12 secret.key.not-so-secret
          drwx------  11 dnusbaum  staff   374B Dec  6 15:12 secrets/
          drwxr-xr-x   5 dnusbaum  staff   170B Dec  6 15:12 updates/
          drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 15:12 userContent/
          drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 15:12 users/
          drwxr-xr-x  25 dnusbaum  staff   850B Dec  6 15:12 war/
          

          Notably, all of the XML files are 0600 instead of 0644 after the AtomicFileWriter changes. My first guess at the problem is that a call to java.io.File#createTempFile was changed to java.nio.file.Files#createTempFile, which from looking through the openjdk source appears to only set OWNER_READ and OWNER_WRITE by default. Should be easy enough to change and test.

          Devin Nusbaum added a comment - - edited I reverted the chmod/mode changes and tested, but the problem was still present. I think this is related to the AtomicFileWriter changes in PR #2548 . Here is a fresh JENKINS_HOME from 2.93: total 64 -rw-------   1 dnusbaum  staff   1.7K Dec  6 14:59 config.xml -rw-r--r--   1 dnusbaum  staff    29B Dec  6 14:59 failed-boot-attempts.txt -rw-------   1 dnusbaum  staff   156B Dec  6 14:59 hudson.model.UpdateCenter.xml -rw-------   1 dnusbaum  staff   1.7K Dec  6 14:59 identity.key.enc -rw-------   1 dnusbaum  staff    94B Dec  6 14:59 jenkins.CLI.xml -rw-r--r--   1 dnusbaum  staff     4B Dec  6 14:59 jenkins.install.UpgradeWizard.state drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 14:59 jobs/ drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 14:59 logs/ -rw-------   1 dnusbaum  staff   907B Dec  6 14:59 nodeMonitors.xml drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 14:59 nodes/ drwxr-xr-x   2 dnusbaum  staff    68B Dec  6 14:59 plugins/ -rw-------   1 dnusbaum  staff    64B Dec  6 14:59 secret.key -rw-r--r--   1 dnusbaum  staff     0B Dec  6 14:59 secret.key.not-so-secret drwx------  11 dnusbaum  staff   374B Dec  6 14:59 secrets/ drwxr-xr-x   4 dnusbaum  staff   136B Dec  6 14:59 updates/ drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 14:59 userContent/ drwxr-xr-x   3 dnusbaum  staff   102B Dec  6 14:59 users/ drwxr-xr-x  25 dnusbaum  staff   850B Dec  6 14:59 war/ If I revert the merge of PR #2548, a fresh JENKINS_HOME looks like: -rw-r--r-- 1 dnusbaum staff 1.7K Dec 6 15:12 config.xml -rw-r--r-- 1 dnusbaum staff 156B Dec 6 15:12 hudson.model.UpdateCenter.xml -rw------- 1 dnusbaum staff 1.7K Dec 6 15:12 identity.key.enc -rw-r--r-- 1 dnusbaum staff 94B Dec 6 15:12 jenkins.CLI.xml -rw-r--r-- 1 dnusbaum staff 4B Dec 6 15:12 jenkins.install.UpgradeWizard.state drwxr-xr-x 2 dnusbaum staff 68B Dec 6 15:12 jobs/ drwxr-xr-x 3 dnusbaum staff 102B Dec 6 15:12 logs/ -rw-r--r-- 1 dnusbaum staff 907B Dec 6 15:12 nodeMonitors.xml drwxr-xr-x 2 dnusbaum staff 68B Dec 6 15:12 nodes/ drwxr-xr-x 2 dnusbaum staff 68B Dec 6 15:12 plugins/ -rw-r--r-- 1 dnusbaum staff 64B Dec 6 15:12 secret.key -rw-r--r-- 1 dnusbaum staff 0B Dec 6 15:12 secret.key.not-so-secret drwx------ 11 dnusbaum staff 374B Dec 6 15:12 secrets/ drwxr-xr-x 5 dnusbaum staff 170B Dec 6 15:12 updates/ drwxr-xr-x 3 dnusbaum staff 102B Dec 6 15:12 userContent/ drwxr-xr-x 3 dnusbaum staff 102B Dec 6 15:12 users/ drwxr-xr-x 25 dnusbaum staff 850B Dec 6 15:12 war/ Notably, all of the XML files are 0600 instead of 0644 after the AtomicFileWriter changes. My first guess at the problem is that a call to java.io.File#createTempFile was changed to java.nio.file.Files#createTempFile , which from looking through the openjdk source appears to only set OWNER_READ  and OWNER_WRITE  by default. Should be easy enough to change and test.

          Devin Nusbaum added a comment - - edited

          Sure enough, after the following patch (edit: which would need to be adjusted to not cause problems on windows) the permissions on the xml files in a fresh JENKINS_HOME are 0644 as before.

          diff --git a/core/src/main/java/hudson/util/AtomicFileWriter.java b/core/src/main/java/hudson/util/AtomicFileWriter.java
          index d63be2648c..c5513c42db 100644
          --- a/core/src/main/java/hudson/util/AtomicFileWriter.java
          +++ b/core/src/main/java/hudson/util/AtomicFileWriter.java
          @@ -37,6 +37,9 @@ import java.nio.file.Path;
          import java.nio.file.StandardCopyOption;
          import java.util.logging.Level;
          import java.util.logging.Logger;
          +import java.util.EnumSet;
          +import java.nio.file.attribute.PosixFilePermissions;
          +import static java.nio.file.attribute.PosixFilePermission.*;
          
          /**
          * Buffered {@link FileWriter} that supports atomic operations.
          @@ -111,7 +114,7 @@ public class AtomicFileWriter extends Writer {
          }
          
          try {
          - tmpPath = Files.createTempFile(dir, "atomic", "tmp");
          + tmpPath = Files.createTempFile(dir, "atomic", "tmp", PosixFilePermissions.asFileAttribute(EnumSet.of(OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ)));
          } catch (IOException e) {
          throw new IOException("Failed to create a temporary file in "+ dir,e);
          }
          

          bharper Can you update the description with an impact of the problem? I.e. Does it cause a failure when you try to restore, etc.

          Devin Nusbaum added a comment - - edited Sure enough, after the following patch (edit: which would need to be adjusted to not cause problems on windows) the permissions on the xml files in a fresh JENKINS_HOME are 0644 as before. diff --git a/core/src/main/java/hudson/util/AtomicFileWriter.java b/core/src/main/java/hudson/util/AtomicFileWriter.java index d63be2648c..c5513c42db 100644 --- a/core/src/main/java/hudson/util/AtomicFileWriter.java +++ b/core/src/main/java/hudson/util/AtomicFileWriter.java @@ -37,6 +37,9 @@ import java.nio.file.Path; import java.nio.file.StandardCopyOption; import java.util.logging.Level; import java.util.logging.Logger; +import java.util.EnumSet; +import java.nio.file.attribute.PosixFilePermissions; +import static java.nio.file.attribute.PosixFilePermission.*; /** * Buffered {@link FileWriter} that supports atomic operations. @@ -111,7 +114,7 @@ public class AtomicFileWriter extends Writer { } try { - tmpPath = Files.createTempFile(dir, "atomic", "tmp"); + tmpPath = Files.createTempFile(dir, "atomic", "tmp", PosixFilePermissions.asFileAttribute(EnumSet.of(OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ))); } catch (IOException e) { throw new IOException("Failed to create a temporary file in "+ dir,e); } bharper Can you update the description with an impact of the problem? I.e. Does it cause a failure when you try to restore, etc.

            batmat Baptiste Mathus
            bharper b harper
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: