If I understand this correctly, it means that changing the permissions allows chrome-sandbox to run as root, retaining root permissions (please correct me if I'm wrong). The character for the setuid/setguid bit is s. You can only assign the setuid/setgid bit by explicitly defining permissions. If you incorrectly assign permissions to a file owned by root with the setuid/setgid bit set, then you can open your system to intrusion. The setuid/setguid permissions are used to tell the system to run an executable as the owner with the owner’s permissions.īe careful using setuid/setgid bits in permissions. I am not familiar with the less common file permissions, but I found the following explanation online: After changing this, Teams started successfully. Inspecting /usr/share/teams/chrome-sandbox the owner was root:root as required, but the permissions were 0755 (rwxr-xr-x) rather than 4755 (rwsr-xr-x). You need to make sure that /usr/share/teams/chrome-sandbox is owned by root and has mode 4755. Rather than run without sandboxing I'm aborting now.
Looking at the $HOME/.config/Microsoft/Microsoft Teams/logs/teams-startup.log file after trying to launch Teams, revealed the following message: The SUID sandbox helper binary was found, but is not configured correctly. However, I have some concerns about the method. In case people are still having trouble getting the latest release (1.7) to work, I managed to get it running.
Pkgdesc="Microsoft Teams for Linux is your chat-centered workspace in Office -14,7 +14,7 \ Here's a simple patch for it, nothing too crazy, just sha256 and version number updated: - PKGBUILD_old 17:18:13.507578928 -0600 The newest version seems to include a couple of quality of life improvements, plus fixes it for the latest version of either wayland on electron (don't know which one, but the current one stopped working for me after a recent update and the latest fixes it)
0 kommentar(er)
