[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2022-01-12 Thread Dan Nicholson
This causes an issue when using glib's gspawn APIs under libseccomp on impish. It uses close_range to set CLOEXEC on some open file descriptors and rightfully checks for ENOSYS. However, since seccomp doesn't know about the syscall that becomes EPERM and it skips setting CLOEXEC assuming there was

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-10-27 Thread Mathew Hodson
** Changed in: libseccomp (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1944436 Title: Please backport support for

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-23 Thread Paride Legovini
Reminds me of LP: #1943049. I mentioned this bug there, as we should make sure that close_range doesn't bring us back to that same issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu.

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-22 Thread Steve Dodd
I think the long test case in #5 now works. Note that later versions of crun have worked around the problem: https://github.com/containers/crun/pull/672 Still worth fixing, though, I think, as it is likely to cause further problems as more code starts to use close_range. -- You received this

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-22 Thread Steve Dodd
Still working out kinks in the above, but here's a simpler one. Needs running in an nspawn container again (steps 1-2 above); should either succeed (no output) or print "function not implemented", but without seccomp support nspawn will block it and it will print "not permitted" #include

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-22 Thread Steve Dodd
It's not going to be simple I'm afraid, at least for the original problem! "scmp_sys_resolver close_range" will quickly test whether current seccomp has support for close_range (prints "-1" if not supported, "436" otherwise - at least on x86_64.) Ubuntu seccomp maintainers have been pretty happy

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-21 Thread Alex Murray
Can you please post a simple reproducer? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1944436 Title: Please backport support for "close_range" syscall Status in

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-21 Thread Steve Dodd
Can confirm rebuilding seccomp in focal with the relevant bits of the above two commits allows me to whitelist close_range in systemd-nspawn, solving my problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

2021-09-21 Thread Steve Dodd
https://github.com/seccomp/libseccomp/pull/322/ (or at least parts of it) probably required too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1944436 Title: Please