Image tag 3.2.2 Thread not permitted

[psulightning]

When attempting to use tag 3.2.2, I am unable to do gem install because of Thread not permitted:

Step 1/23 : FROM ruby:3.2.2
 ---> 41c4505d93f5
Step 2/23 : RUN gem install aws-sdk-secretsmanager
 ---> Running in 75b6669fde2c
ERROR:  While executing gem ... (ThreadError)
    can't create Thread: Operation not permitted
        /usr/local/lib/ruby/3.2.0/timeout.rb:101:in `initialize'
	/usr/local/lib/ruby/3.2.0/timeout.rb:101:in `new'
	/usr/local/lib/ruby/3.2.0/timeout.rb:101:in `create_timeout_thread'
	/usr/local/lib/ruby/3.2.0/timeout.rb:134:in `block in ensure_timeout_thread_created'
	/usr/local/lib/ruby/3.2.0/timeout.rb:132:in `synchronize'
	/usr/local/lib/ruby/3.2.0/timeout.rb:132:in `ensure_timeout_thread_created'
	/usr/local/lib/ruby/3.2.0/timeout.rb:181:in `timeout'
	/usr/local/lib/ruby/3.2.0/net/http.rb:1269:in `connect'
	/usr/local/lib/ruby/3.2.0/net/http.rb:1248:in `do_start'
	/usr/local/lib/ruby/3.2.0/net/http.rb:1243:in `start'
	/usr/local/lib/ruby/3.2.0/rubygems/request/http_pool.rb:43:in `setup_connection'
	/usr/local/lib/ruby/3.2.0/rubygems/request/https_pool.rb:7:in `setup_connection'
	/usr/local/lib/ruby/3.2.0/rubygems/request/http_pool.rb:39:in `make_connection'
	/usr/local/lib/ruby/3.2.0/rubygems/request/http_pool.rb:20:in `checkout'
	/usr/local/lib/ruby/3.2.0/rubygems/request.rb:129:in `connection_for'
	/usr/local/lib/ruby/3.2.0/rubygems/request.rb:188:in `perform_request'
	/usr/local/lib/ruby/3.2.0/rubygems/request.rb:154:in `fetch'
	/usr/local/lib/ruby/3.2.0/rubygems/remote_fetcher.rb:309:in `request'
	/usr/local/lib/ruby/3.2.0/rubygems/remote_fetcher.rb:209:in `fetch_http'
	/usr/local/lib/ruby/3.2.0/rubygems/remote_fetcher.rb:248:in `fetch_path'
	/usr/local/lib/ruby/3.2.0/rubygems/source.rb:88:in `dependency_resolver_set'
	/usr/local/lib/ruby/3.2.0/rubygems/resolver/best_set.rb:23:in `block in pick_sets'
	/usr/local/lib/ruby/3.2.0/rubygems/source_list.rb:94:in `each'
	/usr/local/lib/ruby/3.2.0/rubygems/source_list.rb:94:in `each_source'
	/usr/local/lib/ruby/3.2.0/rubygems/resolver/best_set.rb:22:in `pick_sets'
	/usr/local/lib/ruby/3.2.0/rubygems/resolver/best_set.rb:28:in `find_all'
	/usr/local/lib/ruby/3.2.0/rubygems/resolver/installer_set.rb:170:in `find_all'
	/usr/local/lib/ruby/3.2.0/rubygems/resolver/installer_set.rb:61:in `add_always_install'
	/usr/local/lib/ruby/3.2.0/rubygems/dependency_installer.rb:322:in `resolve_dependencies'
	/usr/local/lib/ruby/3.2.0/rubygems/commands/install_command.rb:205:in `install_gem'
	/usr/local/lib/ruby/3.2.0/rubygems/commands/install_command.rb:230:in `block in install_gems'
	/usr/local/lib/ruby/3.2.0/rubygems/commands/install_command.rb:223:in `each'
	/usr/local/lib/ruby/3.2.0/rubygems/commands/install_command.rb:223:in `install_gems'
	/usr/local/lib/ruby/3.2.0/rubygems/commands/install_command.rb:169:in `execute'
	/usr/local/lib/ruby/3.2.0/rubygems/command.rb:327:in `invoke_with_build_args'
	/usr/local/lib/ruby/3.2.0/rubygems/command_manager.rb:252:in `invoke_command'
	/usr/local/lib/ruby/3.2.0/rubygems/command_manager.rb:192:in `process_args'
	/usr/local/lib/ruby/3.2.0/rubygems/command_manager.rb:150:in `run'
	/usr/local/lib/ruby/3.2.0/rubygems/gem_runner.rb:51:in `run'
	/usr/local/bin/gem:10:in `<main>'

I have also tried moving gem update --system to see if the issue is with gem itself to no avail. If I switch to 3.2.2-bullseye, the build completes successfully.

[yosifkit]

(basically the same comment as docker-library/python#837 (comment) and redis/docker-library-redis#365 (comment))

Root cause: it is Docker with libseccomp so a newer syscall used in Debian Bookworm packages/libs is being blocked.

libseccomp lets you configure allowed syscalls for a process. Docker sets a default seccomp profile for all containers such that only certain syscalls are allowed and everything else is blocked (so, newer syscalls that are not yet known to libseccomp or docker are blocked).

• verify that it is libseccomp by running the Bookworm-based image with --security-opt seccomp=unconfined
  • use only as a test; it is less secure to keep running them "unconfined"
  • learn more: https://docs.docker.com/engine/security/seccomp/
• one fix:
  • update libseccomp and docker on the host running the containers
• one workaround:
  • switch to the *bullseye images (in the ruby images, these will continue to be maintained/updated until the respective Ruby end of life or the next Debian release, Debian Trixie)

[psulightning]

@yosifkit thanks. will use bullseye as a workaround. updating docker if a bit more effort in my situation.