LoadError: Missing Permissions of 1.0.30 release

[pauline-koch]

Hi,

first, thank you so much for this gem.

Unfortunately there is an issue with the permissions in the 1.0.30 release. The files are only readable by the owner, that's causing issues.
Could you add the missing read permissions?

ls -lah /usr/local/bundle/gems/combine_pdf-1.0.30 
total 84K
drwxr-xr-x   5 root root  195 Mar 31 12:25 .
drwxr-xr-x 289 root root  12K Mar 31 12:25 ..
drwxr-xr-x   3 root root   23 Mar 31 12:25 .github
-rw-------   1 root root  129 Mar 31 12:25 .gitignore
-rw-------   1 root root   15 Mar 31 12:25 .travis.yml
-rw-------   1 root root  31K Mar 31 12:25 CHANGELOG.md
-rw-------   1 root root   96 Mar 31 12:25 Gemfile
-rw-------   1 root root 1.2K Mar 31 12:25 LICENSE.txt
-rw-------   1 root root  12K Mar 31 12:25 README.md
-rw-------   1 root root  153 Mar 31 12:25 Rakefile
-rw-------   1 root root 1.3K Mar 31 12:25 combine_pdf.gemspec
drwxr-xr-x   3 root root   47 Mar 31 12:25 lib
drwxr-xr-x   4 root root   91 Mar 31 12:25 test

[qdegraeve]

Hi,

I also encountered issue with theses permissions. below is the backtrace of the issue when loading a Rails application in a docker container with a user different than the one that installed the gems :

There was an error while trying to load the gem 'combine_pdf'.
Gem Load Error is: cannot load such file -- /usr/local/bundle/ruby/3.2.0/gems/combine_pdf-1.0.30/lib/combine_pdf.rb
Backtrace for gem load error is:
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/usr/local/bundle/ruby/3.2.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/usr/local/lib/ruby/site_ruby/3.2.0/bundler/runtime.rb:63:in `block (2 levels) in require'
/usr/local/lib/ruby/site_ruby/3.2.0/bundler/runtime.rb:58:in `each'
/usr/local/lib/ruby/site_ruby/3.2.0/bundler/runtime.rb:58:in `block in require'
/usr/local/lib/ruby/site_ruby/3.2.0/bundler/runtime.rb:52:in `each'
/usr/local/lib/ruby/site_ruby/3.2.0/bundler/runtime.rb:52:in `require'
/usr/local/lib/ruby/site_ruby/3.2.0/bundler.rb:215:in `require'
/home/my_user/app/config/application.rb:21:in `<top (required)>'
/home/my_user/app/config/environment.rb:2:in `require_relative'
/home/my_user/app/config/environment.rb:2:in `<top (required)>'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/usr/local/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/dependencies.rb:332:in `block in require'
/usr/local/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/dependencies.rb:299:in `load_dependency'
/usr/local/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/dependencies.rb:332:in `require'

[boazsegev]

Can anyone explain this one for me? How do the permissions change?

Moreover, how would I be able to control the permissions? Isn't this a system / an installation concern?

B.

[pauline-koch]

Hi,

Thanks for looking into this!

The permissions of files inside a gem are usually set when the gem is built. I checked them by extracting the files via tar from the gem archive.

The fix is in my opinion ensuring that the source files have appropriate permissions before running gem build.
This can be archived by running

chmod -R a+rX .

inside the gem dir for example.
The goal is for all gem files to be readable, as they were in version 1.0.29.

Out of curiosity, what does the current build process look like? Is it automated, or do you build the gem manually on your machine?

Thank you and best regards

Pauline

[boazsegev]

Hi @pauline-koch ,

Thank you for the information and joining the discussion.

The release/build process is fully automated using rake and has been for years. After committing all changes I run:

rake release

As far as I know, the packaged files contain no permission data, as it would be odd to impose permission restrictions on the release package.

Trying to research this issue I always came up with installation related permission issues and blog posts about solving them.

The only reference to a build / release issue was here. A possible workaround is the one you suggested for the repo, by using chmod -R, which is recursive, on the gem folder. i.e.:

sudo chmod -R a+rx /usr/local/bundle/gems/

Having said that, I am keeping an open mind as to the source of the issue, since I released the gem using a different computer and if anything on my end could effect the permissions, this could be it. I'll update the gem file folder on my end, even though I find it somewhat strange that my own security setup should effect another system.

Thanks again,
B.

[davidwessman]

We had to rollback 1.0.30, we got uninitialized constant CombinePDF (NameError) when calling CombinePDF.new.
Probably because we are running with a different user than the one installing the gem (inside Docker container).

[davidwessman]

@boazsegev Do you see any warnings when gem build is run?
Seems like there are some checks for this in rubygems
ruby/rubygems#6078 (comment)

[sander-deryckere]

since I released the gem using a different computer and if anything on my end could effect the permissions, this could be it.

How did you move the code to your new computer? If you copied the files over, or reused the same disk, it's possible the new computer has a different user-id, so the files are no longer owned by you (at least by your new user on your new computer).

Perhaps you could also try changing the owner of the file to yourself:

sudo chown -R owner:group directory/

I.e.

sudo chown -R boazsegev:boazsegev ./combine_pdf/

(we're having the same issue btw, but only on our development environment for now. So waiting if we need to revert to .29 or if we can wait for .31)

[visini]

We're also running into this. For now, we've rolled back to 1.0.29. As others have mentioned, we're also using Docker.

[boazsegev]

How did you move the code to your new computer? If you copied the files over, or reused the same disk, it's possible the new computer has a different user-id, so the files are no longer owned by you (at least by your new user on your new computer).

All my development files are on my iCloud, so I did pretty much nothing to copy the files.

We're also running into this. For now, we've rolled back to 1.0.29. As others have mentioned, we're also using Docker.

I yanked 1.0.30 until we find a fix. I updated permissions to add read to everyone, but I have my doubts if the gem package contains (or should contain) any permission data. This may be a gem Ruby bug... I need to dig in some more.

I'll release a version 1.0.30beta for testing. This should prevent auto-updates.

[pauline-koch]

Great, I just tested 1.0.30beta. The permissions are correct now - no more errors. I think you can release it as 1.0.31. Thank you!

[g-pavlik]

@boazsegev I decided to chime in to give you another data point (I agree the permissions situation is strange, I don't fully understand why was it failing for others):

Since you published 1.30.0, and our dependabot picked it up - we spotted no issues with this version (we merged 1.30.0 Mar 31).

We install this gem on a plethora of different systems: Heroku (Cedar stack), Aptible (Docker image), local devs are installing it on macbooks, linux (dockerized and not).

I don't know if that helps^, but just wanted to share it.

The only issue we had was being locked on 1.30.0 and this version being yanked from rubygems. I'm not familiar with rubygems lifecycle so this is not a criticism - maybe a standard operating procedure in such cases? Something to think about.

ps. we love this gem BTW 😍

[qdegraeve]

@g-pavlik I think the issue was on docker when in Dockerfile you run bundle install before creating a user responsible for the ruby app.
On a local machine or on docker whithout this setup, the user running bundle install is the same than the one running the app so there is no issue