❦ 28 juillet 2019 12:11 +02, Philipp Kern <[email protected]>: >> Just a quick note: seccomp filters may need adaptations from one libc >> to another (and from one kernel to another as the libc may adapt to >> the current kernel). For example, with the introduction of "openat" >> syscall, the libc has started to use it for "open()" and the new >> syscall has to be whitelisted. On the other hand, if you start >> implementing seccomp filters late, you may have whitelisted only the >> "openat" syscall while older libc (or current libc running on older >> kernels) will invoke the "open" syscall. >> >> I am upstream for a project using seccomp since a long time and I have >> never been comfortable to enable it in Debian for this reason. However, >> they enable it in Gentoo and I get the occasional patches to update the >> whitelist (I am not doing anything fancy). > > But technically it should be possible to test this in an autopkgtest, > no? I don't think perfect has to be the enemy of good here, as long as > we can detect breakage and remediate it afterwards?
Yes, but I was thinking to cases where you run kernel from oldstable
with stable for example. This is something currently allowed that may
not work anymore. I am just providing the information, I don't have a
strong opinion if seccomp should or shouldn't be enabled.
--
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
