Q: request of new minor release with an updated syscall table to support newer kernels #406
Comments
pcmoore
changed the title
|
Thoughts @drakenclimber? It's been roughly a year since the last v2.5.x release and while I don't see any significant changes in the release-2.5 branch, and new release with an updated syscall table might be a good idea. |
Yeah, I definitely support doing a new 2.5.x release. I have some obligations that will likely consume the next few weeks, but I should have time after that. Does June or July sound reasonable? |
|
Next week I'm going to be spending some quality time stuck on planes/airports, I might be able to put a release together next week, but I don't want to step on your toes :) I am doing two PRs to update the syscall tables on main and release-2.5, and it looks like we don't need to update main (no syscall changes between v6.2 and v6.3). |
If you have the time and the desire to release v2.5.5, I'm totally cool with that. I know you've been pretty busy lately, so I didn't want to burden you with more work. |
|
I should have time to help review/test the v2.5.5 release if you want a second set of eyes. |
|
Actually, wait a minute ... looking at the syscall table changes between Linux v5.17 (what we shipped in the libseccomp v2.5.4 release) and Linux v6.3 I only see one change: @shaba what problems are you seeing with libseccomp v2.5.4 that you need a new release with updated kernel support? |
|
Related PR to update the release-2.5 branch with the Linux v6.3 syscall information.: |
|
I didn't knew there was no significant syscall changes either. It's good to know release is not needed. We just wanted to have updated libseccomp for actual kernels. For longarch support i can wait next major release. |
|
This summer I'll work on paring down the open issues for 2.6.0. We have a lot of cool features there that I would love to get released. |
Yeah, I've been trying to carve out one day a week to work on libseccomp lately ... although most weeks I've been failing miserably at that :/ |
|
@shaba I'm going to go ahead and close this out as I think we've resolved your concern, but if I'm mistaken please feel free to re-open. |
Sounds all too familiar :) |
|
There are three new syscalls since than already on v6.6-rc1 ( |
|
We are working on a minor release, although there is not set date yet so please don't ask ;) |
|
Because it's impossible to add exact syscall that is present in kernel but not present in libseccomp (such as fchmodat2) it's impossible to create workarounds for adding syscalls (for example just ENOSYS them altogether) that are not yet supported by libseccomp. Please make libseccomp synchronized with the current kernel version? Or allow adding unsupported syscalls? |
See |
Ah thanks. We misinterpreted |
|
glibc starting using fchmodat2 to implement fchmod with flags [1], so the lack of support for fchmodat2 in libseccomp is causing problems with programs sandboxed by systemd. In particular, |
|
@drakenclimber see above. I'll send you an email this morning. |
glibc starting using fchmodat2 to implement fchmod with flags [1], but current version of libseccomp does not support fchmodat2 [2]. This is causing problems with programs sandboxed by systemd. libseccomp needs to know a syscall to be able to set any kind of filter for it, so for syscalls unknown by libseccomp we would always do the default action, i.e. either return the errno set by SystemCallErrorNumber or send a fatal signal. For glibc to ignore the unknown syscall and gracefully fall back to the older implementation, we need to return ENOSYS. In particular, tar now fails with the default SystemCallFilter="@System-service" sandbox [3]. This is of course a wider problem: any time the kernel gains new syscalls, before libseccomp and systemd have caught up, we'd behave incorrectly. Let's do the same as we already were doing in nspawn since 3573e03, and do the "default action" only for syscalls which are known by us and libseccomp, and return ENOSYS for anything else. This means that users can start using a sandbox with the new syscalls only after libseccomp and systemd have been updated, but before that happens they behaviour that is backwards-compatible. [1] bminor/glibc@65341f7 [2] seccomp/libseccomp#406 [2] systemd#30250 Fixes systemd#30250.
|
systemd/systemd#30291 makes systemd handle unknown (to itself or libseccomp) syscalls gracefully by returning ENOSYS. So the ask here is less urgent: things should work as before, but we need an updated libseccomp to allow users to specify |
|
Thanks, @keszybz. That looks like a good addition to systemd. I'm going to start working on the 2.5.5 release right now. It's been long overdue. |
glibc starting using fchmodat2 to implement fchmod with flags [1], but current version of libseccomp does not support fchmodat2 [2]. This is causing problems with programs sandboxed by systemd. libseccomp needs to know a syscall to be able to set any kind of filter for it, so for syscalls unknown by libseccomp we would always do the default action, i.e. either return the errno set by SystemCallErrorNumber or send a fatal signal. For glibc to ignore the unknown syscall and gracefully fall back to the older implementation, we need to return ENOSYS. In particular, tar now fails with the default SystemCallFilter="@System-service" sandbox [3]. This is of course a wider problem: any time the kernel gains new syscalls, before libseccomp and systemd have caught up, we'd behave incorrectly. Let's do the same as we already were doing in nspawn since 3573e03, and do the "default action" only for syscalls which are known by us and libseccomp, and return ENOSYS for anything else. This means that users can start using a sandbox with the new syscalls only after libseccomp and systemd have been updated, but before that happens they behaviour that is backwards-compatible. [1] bminor/glibc@65341f7 [2] seccomp/libseccomp#406 [2] systemd#30250 Fixes systemd#30250.
|
For those watching this issue - I have just released libseccomp v2.5.5. Thanks for all the help 👍 |
glibc starting using fchmodat2 to implement fchmod with flags [1], but current version of libseccomp does not support fchmodat2 [2]. This is causing problems with programs sandboxed by systemd. libseccomp needs to know a syscall to be able to set any kind of filter for it, so for syscalls unknown by libseccomp we would always do the default action, i.e. either return the errno set by SystemCallErrorNumber or send a fatal signal. For glibc to ignore the unknown syscall and gracefully fall back to the older implementation, we need to return ENOSYS. In particular, tar now fails with the default SystemCallFilter="@System-service" sandbox [3]. This is of course a wider problem: any time the kernel gains new syscalls, before libseccomp and systemd have caught up, we'd behave incorrectly. Let's do the same as we already were doing in nspawn since 3573e03, and do the "default action" only for syscalls which are known by us and libseccomp, and return ENOSYS for anything else. This means that users can start using a sandbox with the new syscalls only after libseccomp and systemd have been updated, but before that happens they behaviour that is backwards-compatible. [1] bminor/glibc@65341f7 [2] seccomp/libseccomp#406 [2] systemd#30250 Fixes systemd#30250. In seccomp_restrict_sxid() there's a chunk conditionalized with '#if defined(__SNR_fchmodat2)'. We need to kep that because seccomp_restrict_sxid() seccomp_restrict_suid_sgid() uses SCMP_ACT_ALLOW as the default action.
Can you please release new minor version with just the support of actual kernels?
The text was updated successfully, but these errors were encountered: