Installed rubies (inside of node[:rbenv][:root]/versions) end up moded 0755

[donaldguy]

Despite the essential chmod on versions at the end of the default recipe, the subdirectory containing the actual installed version is not accessible to members of node[:rbenv][:group] other than node[:rbenv][:user]

I tried making

    out = rbenv_command("install #{new_resource.name}")

in providers/ruby.rb into

    out = rbenv_command("install #{new_resource.name}", :umask =>'002')

to no avail. (I verified the umask was making it all the way to Mixlib::ShellOut::Unix#run_command, but the generated dir was still 755. So maybe call that a bug in sstephenson/ruby-build or the ruby Makefiles or something )

Adding a recursive true to the resource in the end of the default recipe also proved ineffective -- digging, this makes sense as all the ACL handling for directory resources is imported whole-cloth from files with no concept of recursion. :-(

Sooooo ... seems like the only option for the present, without requiring upstream changes to either chef or ruby-build is to add an explicit chmod on the directory after the install.

[donaldguy]

... this worked on my first tests. Trying again, I am getting a Insecure operation - load_file (SecurityError) when trying to use gems. (even though nothing should be world writable...)

Investigating ...

[donaldguy]

Ah. Don't know why I didn't hit it before, but the setgid bit is (also) being set on the executables, when we really just want it on the directories ... :-/

[allaire]

Any updates on this? What's the preferred way currently to do things?

[benlangfeld]

We're also experiencing this issue. Will a fix be merged soon?

[subdigital]

I'm stuck by this as well.

[reset]

@donaldguy did you do any testing with your latest changes to this? Has anyone verified this as a fix to the problem?

[subdigital]

At initial glance it looks like the same would need to be done to /opt/rbenv/shims…

On Friday, November 22, 2013 at 10:30 PM, Jamie Winsor wrote:

@donaldguy (https://github.com/donaldguy) did you do any testing with your latest changes to this? Has anyone verified this as a fix to the problem?

— Reply to this email directly or view it on GitHub (https://github.com/RiotGames/rbenv-cookbook/pull/52#issuecomment-29125571).

[donaldguy]

My chef work has been put on hold so I haven't been touching any of this lately and frankly don't remember the state of things at last glance. I am about to go to sleep, but I will try to find some time to play around with this tomorrow evening if no one else has dug through it before then (feel free to)

I did determine (I believe) that even if you manually set a shell to umask 002 and manually run the ruby-build commands, stuff ends up the same way. So the bug is definitely originating further upstream and ideally would see a fix there.

Good night

[sentience]

For anyone looking for a quick-and-dirty workaround to this until a proper solution is found, I’ve put this in my application recipe after the rbenv_ruby resource that installs my ruby:

bash "fix-rbenv-ruby-permissions" do
  user "root"
  code "find #{node[:rbenv][:root_path]}/versions -type d -exec chmod 775 {} +"
  action :run
end

This makes all directories under #{node[:rbenv][:root_path]}/versions group-writable, so that, for example, gems can be installed by anyone in the node[:rbenv][:group] group.

[allaire]

@sentience Thanks for this, it works great.

@reset I still have the same issue with latest version :)

[reset]

@allaire but this seems to fix your problem?

[allaire]

@reset Using the fix provided by @sentience yes. But don't you think this should be handled somehow by the cookbook?

[reset]

@allaire of course, but I wanted to see what solution was the thing that actually solved the problem before writing any code ;)

[sonnysideup]

@reset

Aside from the small fix above, I have tested the changes proposed by @donaldguy and they work fine. The directory permissions/mode look good and I'm able to install/uninstall ruby versions and gems correctly.

[reset]

@drywheat awesome, thank you for helping with this one. @donaldguy do you want to rebase and make the slight changes that @drywheat has pointed out so we can merge your work in?

[donaldguy]

Done. Squashed the two commits.

Sorry that I didn't find the time to re-do the testing more recently :-/. I've been spending all my time in application level java and js, so it was too much of a context switch for my brain.

Thanks for getting to it @drywheat

[donaldguy]

(since I was already doing the rebase, I did another quick amend to remove an extra new line)

[reset]

no problem, thanks for the contribution @donaldguy

[allaire]

Awesome work thanks guys! We'll try this out shortly :)

[allaire]

I don't want to be a party pooper, but this PR didn't fix it for me and I still need the fix from @sentience. I think the difference is his fix runs on each chef-run, not only after a new ruby version install.

[sonnysideup]

Did you try it out using a fresh install? It will not set the proper mode if the system has already been configured.

[allaire]

Edit

My bad, cookbook was froze and I thought Berkshelf overwrote it :)

So maybe we should bump version? :D

[reset]

@allaire I didn't release a new version to the community site. I'd strongly suggest not using Git locations to resolve your cookbooks to avoid issues like this one ;).

I'll release a new version to the community site right now

[allaire]

@reset Gotcha master! Thanks