© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Are we sure this issue doesn't affect 24.04? This bug was filed on 27 March, a day after libseccomp 2.5.5-1ubuntu1 was published into the Noble release pocket. It looks like this was first fixed upstream in 2.5.5. The original reporter (understandably) did not report the version of the libseccomp package used. After fixing the Test Plan as I've requested below, please run that against 24.04 to make sure, and report the results.
Presumably this bug isn't currently fixed in 23.10 since 2.5.4-1ubuntu3 is current there. This is a prerequisite to fixing 22.04. Please see https:/
> On an ARM 64 machine install the latest version of docker on a jammy host by following the official docker documentation. [https:/
Please update the Test Plan to use Docker as shipped by Ubuntu. Or, if this issue only affects a version of Docker external to the Ubuntu archive, then we might still be able to fix libseccomp for you, but it changes the calculus considerably. Please document the specifics, and tie it to a specific version that has specific behaviour (what, exactly?) rather than the moving target of "latest".
> However docker seccomp profile defaults to returning EPERM for all non defined syscalls and writing an entry for fchmodat2 in the docker seccomp profile to return ENOSYS does not work on systems where libseccomp does not have support for fchmodat2.
Will libseccomp allow Docker to return ENOSYS for all non defined syscalls instead? This seems like it would be the correct general fix to me, to avoid future breakages of the same class. Is this possible, and how would doing this instead change the risk to 22.04 in this fix? If this issue only affects an upstream version of Docker, can that be fixed there please, rather than risking regression to all other libseccomp consumers by working around this in libseccomp in 22.04? Then I think your "use the latest version of upstream Docker" would just start working?
The proposed patch looks like it adds system call numbers for fchmodat2 for all architectures, as well as for a bunch of other system calls. The architecture-
Following "the requirements for stable updates are not necessarily the same as those in the development release" from https:/
Or, if the problem we're solving is wider than this and requires the full patch, then I think we need to include that in our regression analysis please, together with a Test Plan that exercises relevant code paths.
In particular, I'm concerned that the proposed change will affect much more than the bug being fixed, increasing regression risk including to other consumers of libseccomp, and that these additional cases aren't covered by the Test Plan. Many more system calls could suddenly "start working" from the perspective of glibc, rather than returning EPERM, depending on how libseccomp is being used. As well as changing behaviour in undetermined ways, this could also have security implications.
I'd much prefer to see just the fchmodat2 syscall arranged to return ENOSYS rather than EPERM, to meet glibc's expectations. This would seem to be the minimalist safe fix to me. Is it possible to hack that in as a magic number? If this isn't possible, then I'd like to see a documentation as to why, please, including for example why Docker cannot arrange ENOSYS for all unknown system calls. And if that's not possible, then can we just touch fchmodat2 in libseccomp in 22.04, rather than messing with other system calls as well?
Sorry I can't give you a specific set of things that I want to see yet - it depends on answers to my various questions above. I'm also sure that there are gaps in my understanding - feel free to fill those in. The key thing is that this is all documented please, such that it is made clear to someone unfamiliar with the specifics why a wide-reaching change is necessary and why a more minimal fix is not possible.