Teams seems to fail with glibc-2.35 due to sandboxing problems even when glibc has the -clone3 patch. Luckily the Arch bug tracker has a solution (see $URL). I don't know if glibc-2.34-r10 without the recently removed clone3 patch is also affected. Reproducible: Always Steps to Reproduce: 1. upgrade to glibc-2.35 2. start teams 3. broken application startup I added --disable-seccomp-filter-sandbox to /usr/bin/teams (which already contained --disable-namespace-sandbox --disable-setuid-sandbox) and it started working again right away. I understand seccomp but do not know whether this constitutes an acceptable security risk due to the nature of JavaScript injection or whatever else Teams may do. Nevertheless this might be an acceptable workaround until a new upstream version is available.
Yeah, it's probably rseq.
Same issue and the suggested workaround fixes it. Thanks!
Appreciate the workaround
Can someone test with teams-1.5.00.10453?
(In reply to Stephan Hartmann from comment #4) > Can someone test with teams-1.5.00.10453? Just copying 1.4.00.26453-r1 to 1.5.00.10453 works for me (at least with respect to the reported problem, have not tested extensively).
(In reply to Kobboi from comment #5) > (In reply to Stephan Hartmann from comment #4) > > Can someone test with teams-1.5.00.10453? > > Just copying 1.4.00.26453-r1 to 1.5.00.10453 works for me (at least with > respect to the reported problem, have not tested extensively). I have pushed the update to the tree already ;)
(In reply to Stephan Hartmann from comment #4) > Can someone test with teams-1.5.00.10453? With glibc-2.35-r2 (-clone3 for other reasons) this version starts fine - no need for any sandbox workarounds. Thank you!
(In reply to Holger Hoffstätte from comment #7) > (In reply to Stephan Hartmann from comment #4) > > Can someone test with teams-1.5.00.10453? > > With glibc-2.35-r2 (-clone3 for other reasons) this version starts fine - no > need for any sandbox workarounds. Thank you! Thanks.
