backport time64 syscalls whitelist
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
docker.io (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bionic |
New
|
Undecided
|
Unassigned | ||
Disco |
Won't Fix
|
Undecided
|
Unassigned | ||
Eoan |
New
|
Undecided
|
Unassigned | ||
Focal |
New
|
Undecided
|
Unassigned | ||
libseccomp (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Triaged
|
Undecided
|
Unassigned | ||
Disco |
Won't Fix
|
Undecided
|
Unassigned | ||
Eoan |
Triaged
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
A number of new *time64 syscalls are introduced in newer kernel series (>=5.1.x):
403: clock_gettime64
404: clock_settime64
405: clock_adjtime64
406: clock_getres_time64
407: clock_nanosleep
408: timer_gettime64
409: timer_settime64
410: timerfd_gettime64
411: timerfd_settime64
412: utimensat_time64
413: pselect6_time64
414: ppoll_time64
In particular utimensat_time64 is now used inside glibc>=2.31
In turn ubuntu with has trouble running docker images of newer distros.
This problem affects libseccomp<2.4.2, ie bionic (lts), and eoan, but not focal.
See a similar report at Fedora: https:/
A solution could be to backport the related changes from 2.4.2 similarly to what happened for the statx whitelisting (https:/
description: | updated |
Changed in docker.io (Ubuntu Disco): | |
status: | New → Won't Fix |
The attachment "backport time64 syscalls from 2.4.2 into 2.4.1" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]