Do not hard-code permissions for new gem directories during bundle install

[maxfelsher-cgi]

What was the end-user or developer problem that led to this PR?

This fixes #9395. Without this change, when running bundle install, any newly created gem directory has permissions rwxr-xr-x regardless of umask settings and regardless of the set-group-ID bit of the parent directory. This makes it much harder to remove gems in a multi-user environment (for example, where different developers have conducted deployments). It also differs from the behavior of gem install ..., which does respect the umask and the set-group-ID bit.

What is your fix for the problem, implemented in this PR?

The mode: 0o755 argument was removed from the FileUtils.mkdir_p call that creates the new directory for the gem being installed. This avoids setting specific permissions and lets the system's default permission handling (such as umask and set-group-ID bits) function.

The hard-coding was originally set up in 79386f4 as part of what appeared to be an unrelated reimplementation of Bundler::RubyGemsGemInstaller#install. Previous to that commit, Bundler::RubyGemsGemInstaller was using the implementation in the parent class, GemInstaller#install. In the commit, the implementation from GemInstaller was copied and then modified to fit Bundler's needs, removing code that wasn't necessary for Bundler. However, I believe a mistake was made during that modification. In the GemInstaller implementation, the relevant lines looked like this:

rubygems/lib/rubygems/installer.rb

Lines 303 to 304 in 79386f4

	dir_mode = options[:dir_mode]
	FileUtils.mkdir_p gem_dir, :mode => dir_mode && 0755

In that case, if options[:dir_mode] was nil, then the resulting call was FileUtils.mkdir_p gem_dir, :mode => nil, which was equivalent to FileUtils.mkdir_p gem_dir. If options[:dir_mode] was truthy, then the call was FileUtils.mkdir_p gem_dir, :mode => 0755. (Note that there was a line further down that ran File.chmod(dir_mode, gem_dir) if dir_mode.) My impression is that usually options[:dir_mode] is not set.

After 79386f4, the Bundler implementation was:

rubygems/bundler/lib/bundler/rubygems_gem_installer.rb

Line 22 in 79386f4

FileUtils.mkdir_p gem_dir, :mode => 0o755

This made it so that the FileUtils.mkdir_p call always set the mode parameter, instead of hardly ever. I suspect that the code dir_mode && 0755 (using the short-circuiting operator) may have been misread as dir_mode & 0755 (using the bitwise AND method). The bitwise-AND reading was how I read the code at first glance, and it would make sense that such an interpretation would lead someone to change the code to simply 0755 when removing dir_mode.

There have been some updates to both implementations since 79386f4, but nothing that affects the reasoning above. I saw no mentions of the permissions change in the commit message or associated pull request, and given that gem install continues to have the old behavior, I believe the change was unintentional. It is much more complicated to fix the permissions after the fact without invoking superuser privileges, so I think the right place to make the adjustment is here, where the files are being created.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags