fails on older linux kernels

[etcusrvar]

I'm running ruby on a linux device with a 3.10.x kernel (I'm not able to update the kernel.) I've installed ruby via homebrew.

Running a simple script

require 'tmpdir'
temp_dir = Dir.mktmpdir

fails with

/home/linuxbrew/.linuxbrew/Cellar/ruby/3.4.4/lib/ruby/3.4.0/tmpdir.rb:152:in 'Random.urandom': failed to get urandom (RuntimeError)
	from /home/linuxbrew/.linuxbrew/Cellar/ruby/3.4.4/lib/ruby/3.4.0/tmpdir.rb:152:in 'next'
	from /home/linuxbrew/.linuxbrew/Cellar/ruby/3.4.4/lib/ruby/3.4.0/tmpdir.rb:176:in 'Dir::Tmpname.create'
	from /home/linuxbrew/.linuxbrew/Cellar/ruby/3.4.4/lib/ruby/3.4.0/tmpdir.rb:99:in 'Dir.mktmpdir'
	from mktmp.rb:2:in '<main>'

This is a similar issue to ruby/rubygems#5941.
One fix would be to use openssl the same way they do in ruby/securerandom@fbce06e

[rhenium]

I'm curious why Random.urandom is failing on Linux 3.10. Could you run the script under a debugger or strace to see it?

On Linux systems without getrandom(2) support (i.e., Linux < 3.17), Random.urandom should fallback to reading from /dev/urandom. If neither source is available, I'd expect it to still fail even with #51, as OpenSSL on Linux also relies on getrandom(2) and /dev/urandom to seed its RNG.

[etcusrvar]

They both say getrandom is not implemented, both fall back to /dev/urandom, and both appear to read from /dev/urandom fine. I'm not sure what openssl is doing beyond the Random.urandom implementation. It could be the O_CLOEXEC flag, I'm not sure.

Random.urandom fails:

$ strace ruby -e "puts Random.urandom(1).unpack1('H*')"
...
getrandom(0x7fff4a9ccf90, 16, GRND_INSECURE) = -1 ENOSYS (Function not implemented)
openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 5
read(5, "e\215&\202\305\264\367p6\367I\302\35\205zh", 16) = 16
getrandom(0x7f1992e42538, 1, 0)         = -1 ENOSYS (Function not implemented)
ioctl(2, TCGETS, 0x7fff4a9ce430)        = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-e:1:in 'Random.urandom': failed"..., 86-e:1:in 'Random.urandom': failed to get urandom (RuntimeError)
	from -e:1:in '<main>'
) = 86

OpenSSL::Random.random_bytes succeeds:

$ strace ruby -e "require 'openssl'; puts OpenSSL::Random.random_bytes(1).unpack1('H*')"
...
getrandom(0x7f6d27ef1d10, 48, 0)        = -1 ENOSYS (Function not implemented)
getrandom(0x7f6d27ef1d10, 48, 0)        = -1 ENOSYS (Function not implemented)
shmget(0x72, 1, 000)                    = 0
shmat(0, NULL, SHM_RDONLY)              = 0x7f6d25f7d000
openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 6
newfstatat(6, "", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x9), ...}, AT_EMPTY_PATH) = 0
read(6, "\322\31`H1)$3\232\0222\306\374\373\\0&\307eeT\361*\344W\220\2151\301\356/d"..., 48) = 48
getpid()                                = 24587
rt_sigaction(SIGINT, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f6d25616ac0}, {sa_handler=0x7f6d25b4a830, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f6d25616ac0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f6d25616ac0}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f6d25616ac0}, 8) = 0
write(1, "b5\n", 3b5
)                     = 3

[rhenium]

Random.urandom fails:

$ strace ruby -e "puts Random.urandom(1).unpack1('H*')"
...
getrandom(0x7fff4a9ccf90, 16, GRND_INSECURE) = -1 ENOSYS (Function not implemented)
openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 5
read(5, "e\215&\202\305\264\367p6\367I\302\35\205zh", 16) = 16

These calls appear to be coming from somewhere else (possibly YJIT/Rust initialization), judging from the length (16 bytes) and the flag (GRND_INSECURE).

/dev/urandom looks functional on this system.

getrandom(0x7f1992e42538, 1, 0)         = -1 ENOSYS (Function not implemented)
ioctl(2, TCGETS, 0x7fff4a9ce430)        = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-e:1:in 'Random.urandom': failed"..., 86-e:1:in 'Random.urandom': failed to get urandom (RuntimeError)
	from -e:1:in '<main>'
) = 86

Random.urandom is not attempting to read from /dev/urandom when it should.

Are you using a libc that provides getentropy(), e.g. glibc 2.25+ or musl 1.1.20+?

I think Ruby 3.1 may have introduced a regression. That the getentropy() symbol exists doesn't mean it's usable, and if it fails, it should still fall back to /dev/urandom as a last resort.
ruby/ruby@54c9118

[etcusrvar]

Are you using a libc that provides getentropy(), e.g. glibc 2.25+ or musl 1.1.20+?

$ /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.36.

I think Ruby 3.1 may have introduced a regression.

I think you're on to something. Homebrew has prebuilt binaries for ruby 3.0 - 3.4, and also homebrew-portable-ruby.
ruby -e "Random.urandom(1)" fails for ruby 3.1-3.4, but succeeds for ruby 3.0 and homebrew-portable-ruby 3.4.

Since this no longer seems like an issue with tmpdir per se, I can open this issue with ruby.
Thanks for narrowing this down.

[rhenium]

Thanks for checking it. I filed https://bugs.ruby-lang.org/issues/21448 for Random.urandom.

[rhenium]

Sorry I forgot to update this issue. Random.urandom should now be fixed in Ruby 3.3.9 and 3.4.5.