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

hardcoded umask in com.sun.akuma/Daemon.java

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      RHEL 5.4
    • Similar Issues:

      Description

      Hello,

      When running hudson via winstone as below.

      /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DHUDSON_HOME=/var/lib/hudson -jar /usr/lib/hudson/hudson.war --logfile=/var/log/hudson/hudson.log --daemon --httpPort=8080 --debug=9 --handlerCountMax=100 --handlerCountMaxIdle=20

      The umask of all the files created are set as 027 rather than the user who invokes the processes umask.

      For example a user with a umask of 022 runs hudson and a job and all the resulting files are set to 027.

      This is because the Daemon.java file that is part of akuma has a call to

      LIBC.umask(0027);

      Please can this be made user configurable or use the inherent umask of the running user.

      Thanks

      Steve Goodliff

        Attachments

          Activity

          sgoodliff sgoodliff created issue -
          Hide
          brucepainter brucepainter added a comment -

          We are encountering this same issue with Hudson 1.353, and it is actually a big issue for us.
          It would be great if this could be changed soon, or at least a workaround published.

          We are looking at having to move our build process into shell scripts and then just have those shell scripts launched by the Hudson build process with the hope that it resolves this issue.

          Show
          brucepainter brucepainter added a comment - We are encountering this same issue with Hudson 1.353, and it is actually a big issue for us. It would be great if this could be changed soon, or at least a workaround published. We are looking at having to move our build process into shell scripts and then just have those shell scripts launched by the Hudson build process with the hope that it resolves this issue.
          Hide
          olo olo added a comment -

          We have the same problem; the sites generated by Maven site build are all initially inaccessible to Apache server until we launch chmod. We've placed it as a shell build step, but it's a dirty workaround and it took some time to figure out.

          Setting hardcoded umask is a silly thing when done en masse and should only be performed temporarily, for really security critical tasks (like the process creating some temporary file with a private key).

          Show
          olo olo added a comment - We have the same problem; the sites generated by Maven site build are all initially inaccessible to Apache server until we launch chmod. We've placed it as a shell build step, but it's a dirty workaround and it took some time to figure out. Setting hardcoded umask is a silly thing when done en masse and should only be performed temporarily, for really security critical tasks (like the process creating some temporary file with a private key).
          mindless Alan Harder made changes -
          Field Original Value New Value
          Description
          Hello,

          When running hudson via winstone as below.

          /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DHUDSON_HOME=/var/lib/hudson -jar /usr/lib/hudson/hudson.war --logfile=/var/log/hudson/hudson.log --daemon --httpPort=8080 --debug=9 --handlerCountMax=100 --handlerCountMaxIdle=20

          The umask of all the files created are set as 027 rather than the user who invokes the processes umask.

          For example a user with a umask of 022 runs hudson and a job and all the resulting files are set to 027.

          This is because the Daemon.java file that is part of akuma has a call to

              LIBC.umask(0027);

          Please can this be made user configurable or use the inherent umask of the running user.

          Thanks

          Steve Goodliff
          Hello,

          When running hudson via winstone as below.

          /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DHUDSON_HOME=/var/lib/hudson -jar /usr/lib/hudson/hudson.war --logfile=/var/log/hudson/hudson.log --daemon --httpPort=8080 --debug=9 --handlerCountMax=100 --handlerCountMaxIdle=20

          The umask of all the files created are set as 027 rather than the user who invokes the processes umask.

          For example a user with a umask of 022 runs hudson and a job and all the resulting files are set to 027.

          This is because the Daemon.java file that is part of akuma has a call to

              LIBC.umask(0027);

          Please can this be made user configurable or use the inherent umask of the running user.

          Thanks

          Steve Goodliff
          Component/s core [ 15593 ]
          Hide
          brucepainter brucepainter added a comment -

          We have come up with a workaround solution for this as well, but are now finding that this is impacting other groups in our organization now that we are upgrading them from old versions of Hudson.

          Is this something that can be addressed?
          How can we go about getting some traction on this issue?

          Show
          brucepainter brucepainter added a comment - We have come up with a workaround solution for this as well, but are now finding that this is impacting other groups in our organization now that we are upgrading them from old versions of Hudson. Is this something that can be addressed? How can we go about getting some traction on this issue?
          Hide
          dallas_clement dallas_clement added a comment -

          I'm completely blocked because of this issue. I'm using Hudson to build a large quantity of C code. Because the umask is hard-coded to something stricter than 02, the file permissions on most of the files that are checked out from my repository lack world or even group permissions. My build is failing because certain utilities like dpkg require group and world permissions. That's just one example. Adding a chmod build step just makes an even bigger mess.

          I think Hudson is a really great tool and I'd like to use it on this project, but not able to proceed further until this is resolved. I'd be glad to help fix it myself if someone could point me in the right direction.

          Show
          dallas_clement dallas_clement added a comment - I'm completely blocked because of this issue. I'm using Hudson to build a large quantity of C code. Because the umask is hard-coded to something stricter than 02, the file permissions on most of the files that are checked out from my repository lack world or even group permissions. My build is failing because certain utilities like dpkg require group and world permissions. That's just one example. Adding a chmod build step just makes an even bigger mess. I think Hudson is a really great tool and I'd like to use it on this project, but not able to proceed further until this is resolved. I'd be glad to help fix it myself if someone could point me in the right direction.
          Hide
          jkavery1 jkavery1 added a comment -

          I used a workaround that perhaps isn't as painful. Builds using Perforce point their Path to p4 executable to this script:

          p4 script
          umask 0022
          exec /usr/local/bin/p4 "$@"
          

          For builds using Ant, there is:

          ~/.antrc
          umask 0022
          
          Show
          jkavery1 jkavery1 added a comment - I used a workaround that perhaps isn't as painful. Builds using Perforce point their Path to p4 executable to this script: p4 script umask 0022 exec /usr/local/bin/p4 "$@" For builds using Ant, there is: ~/.antrc umask 0022
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/pom.xml
          http://hudson-labs.org/commit/core/604f68a1f28a354ab1511f5198de953f47a62737
          Log:
          [FIXED JENKINS-5114] don't hard code umask to 027.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: Kohsuke Kawaguchi Path: changelog.html core/pom.xml http://hudson-labs.org/commit/core/604f68a1f28a354ab1511f5198de953f47a62737 Log: [FIXED JENKINS-5114] don't hard code umask to 027.
          scm_issue_link SCM/JIRA link daemon made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 135198 ] JNJira + In-Review [ 186942 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              sgoodliff sgoodliff
            • Votes:
              9 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: