appelier/bigtuna

Builds are created with 0777 permissions

Closed this issue · 6 comments

Is there a good reason for this? I'm running on an Ubuntu Lucid 2.6.32-309-ec2 with Passenger. I have problems with this because bundler throws up red flags when the bundle folder inherits the 0777 permissions.

Besides that if there is no very good reason for this, just in the context of security maybe it should be addressed.

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.

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

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

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 ? :)

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

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