Cache permissions and umask issues after switch to mkstemp

[kpumuk]

This PR resolves multiple permissions-related issues introduced in #240.

State before the change

• When directory does not exist, it is being created with mkpath (respects umask, default permissions 0775), and then file opened with open (respects umask, default permissions are 0664).
• When the second file is created in the same directory, it uses mkstemp, which always creates files with permissions 0600. This causes various issues when permissions system relies on user groups, as the group can no longer read or write cache files.

After this change

• After directory first created, we use open to create first file.
• The second file is created with mkstemp call, which sets permissions to 0600.
• To fix permissions, we apply 0644 to the file after rename, and properly use umask value (current umask is determined in the Init_bootsnap)

I have tested this change with and without umask, and it seems to be working properly:

• By default directories are created with 0775
• Files are created with 0664
• When umask 022 is specified, directories are 0755 and files are 0644

Previous behavior that was reverted by mkstemp

• be4e847

Related issues

• Unable to load application: Bootsnap::CompileCache::PermissionError #254 Unable to load application: Bootsnap::CompileCache::PermissionError
• Atomic write cache file error. #171 Atomic write cache file error

Updates

I was wrong about the second open call, it makes sense now and PR is corrected. ;-) The pemissions issue is still there.

[burke]

Oh, this looks great. Thank you!

[kpumuk]

Thank you!

[markets]

Thanks a lot for working on this! 🙌

We're having the same issue deploying with Capistrano a newish Rails 5.2 app with Bootsnap 1.4.2, so we temporary disabled Bootsnap. Any plans to cut a new release?

[ansonhoyt]

@markets 1.4.3 has been released. I'm re-enabling in production now too.

[markets]

Thanks @ansonhoyt will try asap!