Builds are created with 0777 permissions about bigtuna

[seankibler]

I retract my statement above regarding bundler throwing red flags. I just had a successful build with bundler with the funky permissions.

I still question whether it is necessary to have wide open permissions on the builds folder though.

[mreinsch]

Still seeing this though:

(in /srv/dep/bigtuna/shared/builds/prj/build_9_20110224092312)
/usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/runtime.rb:136: warning: Insecure world writable dir /srv/dep/bigtuna/releases/20110224091425/builds/prj/bundle/ruby/1.8/bin in PATH, mode 040777
rake aborted!
no such file to load -- sqlite3

bundler then seems to picks up bigtuna's Gemfile for building the project, which of course fails the build.

BTW, I only got that far because I specified --gemfile in the bundler install call...

[mreinsch]

The culprit for this is Ruby's daemons library. Someone thinks that 000 is a sensible umask.
Anyway, there is still something else strange going on, because builds still fail because bundler isn't setting up the environment correctly...

[antekpiechnik]

I did make the 'builds' folder start with 0754 permissions in this commit: f34335a, but that didn't change the subdirectories' (projects/builds) permissions. They vary from 0777 to 0755. Any ideas ? :)

[mreinsch]

as I tried to explain, the issue is actually in how the delayed_job daemon is run. It uses the Ruby's daemons library which sets the umask (hard coded) to 000.
I dropped the daemons library for myself (it isn't any good anyway, imho) with a little modification to the delayed_job script, and using daemontools as explained there: http://www.mobalean.com/blog/2010/08/16/delayed_job-and-other-daemons-in-a-production-environment

[antekpiechnik]

Ok then, seems like it's more of a job for deamons library guys :) Thanks for the insight!