• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • RHEL 5.4

      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

          [JENKINS-5114] hardcoded umask in com.sun.akuma/Daemon.java

          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.

          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.

          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).

          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).

          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?

          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?

          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.

          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.

          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
          

          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

          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/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.

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

              Created:
              Updated:
              Resolved: