this is gonna read like a wild doomsday claim, but here it is anyway
we’re in the fourth month of an even numbered year. that’s always been the time Ubuntu releases a new version that will become the next LTS release.
https://packages.ubuntu.com/search?keywords=libc6&searchon=names&suite=all§ion=all
| release | version |
|---|---|
| 16.04 LTS (currently used on Glitch) | 2.23 |
| 18.04 LTS | 2.27 |
| 20.04 LTS | 2.31 |
| 21.10 | 2.34 |
| jammy | 2.35 |
if we take a look at this package listing of glibc across Ubuntu versions, it looks like the next one will be at least version 2.35. meanwhile, the current LTS release, 20.04, uses 2.31.
incidentally, something has happened in glibc in between these versions. in 2.33, they started using a new syscall, faccessat2
the current kernel version on Glitch’s hosts (4.4) doesn’t have faccessat2 (added in 5.8), but that’s not too bad. there’s code to detect that and fall back to the old way of doing it: (comments added)
if (ret == 0 || errno != ENOSYS) // We have permission. // Or we've received a reason why we don't have permission. // Or some problem occurred. return ret; // Otherwise, we got ENOSYS which means the syscall isn't supported. // Do it the same way as before.
however, in some experiments on compiling a newer suite of software for Glitch containers, I found that an issue in Glitch’s container system—an old-ish version of Docker?—breaks this unavailable-syscall detection.
I’ve made a demo of this behavior, with a little program that directly does a faccessat2 syscall:
// long number = SYS_faccessat2; // not defined long number = 439; // numeric faccessat2, linux 4.4 doesn't have this yet, so should give ENOSYS, instead gives EPERM // long number = 9999995; // some high number, unknown syscall should give ENOSYS, instead gives EPERM
we don’t get ENOSYS from Glitch. we get EPERM. and glibc treats that as “we were able to call faccessat2, and it said that we have no permission to read/write/whatever the file you asked about.”
and this glibc function, faccessat, turns out to come up in a lot of places. for example, a simple rm myfile with a rm program built on glibc 2.33+ on Glitch will fail with Operation not permitted. (this actually happened to me today. weird way to spend a wednesday night huh?)
so here’s where we are, on the cusp of “the latest Ubuntu LTS release” being something that’ll be drastically broken if Glitch were to pull some mythical trigger and upgrade containers to it. well, if they were to do that without simultaneously pulling some other mythical trigger that upgrades their container system 