Observations on future-readiness

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.


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 :woman_shrugging:


Hey @wh0 thanks so much for the report!

Upgrading the platform’s OS is something we’ve wanted to be able to get to for a long time, and while I’d like to hope we’d’ve caught this in testing, you’ve certainly saved us a bunch of time digging into the details - sorry you had to spend your Wednesday night doing so!

I’ve added this to our backlog so when we start planning that work we’ll keep it in mind!

Thanks as always for helping us keep Glitch safe and reliable!