On Tue, 28 Sep 2021 09:52, Thorsten Kukuk wrote:
On Mon, Sep 27, Cristian Rodríguez wrote:
Yes, it is easy to understand it backwards..
glibc only guarantees binary level
compatibility and adherence to the relevant standards , it does not cover which
operating system facilities it uses for implementing things.
Now it implements stuff on top of extremely powerful newish clone3() syscall
and some apps do not like that.
The problem is more: too many people did not take it serious enough that
glibc will use clone3() in the future. Some projects were sitting for
about 6 month on fixes but did not include them or release fixed packages...
The main problem is, that most projects using seccomp for sandboxing don't
really think about the future, but only the past. So they look at what
is currently in use and forbid everything else with "ENOPERM". And are
surprised if suddenly new syscalls are added and their code breaks
It would always be better to block unknown syscalls with "ENOSYS", so
letting the application think the new syscall still does not exist. This
gives the application (or in this case better glibc) the chance to use the
old code as fallback.
As long as the sandbox developers don't make their code future proof, we
will have this problem again and again with every new syscall.
+1 Thank you Thorsten, for the compact insight into the causes behind the
Looking at my own coding efforts wrt. sandboxing, I can see the issue.
Thankfully my teachers (more than two decades back) told me:
"Do not say 'permission fail' if a unknown syscall comes, that is
a 'system fail'. 'Permission fail' is only a known op abused."
Non the less, your words hit the nail on the head. Thank you for that.