Package Details: zoom 6.3.6-1

Git Clone URL: https://aur.archlinux.org/zoom.git (read-only, click to copy)
Package Base: zoom
Description: Video Conferencing and Web Conferencing Service
Upstream URL: https://zoom.us/
Keywords: call conference meeting video
Licenses: LicenseRef-zoom
Submitter: edh
Maintainer: edh
Last Packager: edh
Votes: 676
Popularity: 7.74
First Submitted: 2015-08-15 13:18 (UTC)
Last Updated: 2025-01-17 02:35 (UTC)

Dependencies (31)

Sources (1)

Pinned Comments

erbrecht commented on 2024-11-19 13:06 (UTC)

@Rhinoceros - I finally got screen sharing to work under KDE with Wayland. Looks like I'm using the same versions as you:

  • Zoom 6.2.10
  • pipewire 1.2.6

I followed the Screen share section on the Zoom wiki page:

https://wiki.archlinux.org/title/Zoom_Meetings

The only thing I didn't need to do was set XDG_CURRENT_DESKTOP=gnome. I followed the other steps, and now I can choose my desktop/window to share. Prior to following the wiki I couldn't stop screen sharing without the hanging issue, which I was experiencing prior to 6.2.10.

edh commented on 2016-08-26 11:03 (UTC) (edited on 2017-03-09 10:48 (UTC) by edh)

I contacted the zoom support on 13th July 2016 and tried to lure them into creating a proper PKGBUILD respectively adopting this one, considering they are providing a package over very none standard ways to the Arch Linux community (downloading via a *foreign* site) and not through the official repo or the AUR. However there was little to no progress so far.

Latest Comments

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 80 Next › Last »

nicktee commented on 2023-01-05 05:31 (UTC) (edited on 2023-01-06 03:20 (UTC) by nicktee)

~~When I run 5.13.3-1 it freezes up my Gnome session. Can't find any indication of why in any logs I can find (~/.zoom/logs/* or journal).~~

Actually ignore this, it looks like an issue with electron, not zoom or this package specifically.

ttshaw1 commented on 2022-12-22 03:27 (UTC)

Is anyone else having trouble with scheduled meetings? I'm using KDE Wayland and Zoom silently crashes when I try to schedule a meeting or join a scheduled meeting. It's been like this for at least a few months

edh commented on 2022-11-30 15:49 (UTC)

Personally, I rather expose myself to kernel-bugs than chrome-sandbox bugs (in a binary-only version of it as packaged by zoom!). If there is no consensus to the contrary, I would not set the SUID bit.

eclairevoyant commented on 2022-11-30 05:22 (UTC) (edited on 2022-11-30 05:25 (UTC) by eclairevoyant)

@hawath pretty sure flatpaks also require unprivileged user namespaces, so you'll run into the same issue there. Also, I don't see what additional benefits a flatpak would provide here.

If the only issue for you is the setuid being off, you can edit the PKGBUILD and turn it on right?

W47MPUSv commented on 2022-11-30 04:48 (UTC)

@eclairevoyant Thank you for your informative reply. I decided to try the flatpak version of Zoom.

eclairevoyant commented on 2022-11-28 23:03 (UTC) (edited on 2022-11-28 23:12 (UTC) by eclairevoyant)

Fair enough on the version. Regarding kernel.unprivileged_userns_clone=0, the attack surface is reduced because you're only using setuid on specific programs rather than allowing all users and all programs to create user namespaces. Also, oops, I meant to provide a link to this Security SE topic, not ServerFault. As mentioned there:

The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs.

In both scenarios (zoom with setuid but without unprivileged user namespaces, vs zoom with unprivileged user namespaces), zoom has root access. However, in the second scenario, potentially any other program also has root access.

That being said, in the second scenario, the program has to do some work to take advantage of a privesc vuln to break out of the container. In the first scenario you've already given it root for free. So FWIW I'm personally in favour of not using setuid.

IMO if you need the security of a hardened kernel in a desktop environment, you either shouldn't be running zoom or you should keep your valuable data on a separate machine/network (that way it doesn't matter if zoom runs as root).

edh commented on 2022-11-28 22:06 (UTC)

@eclairevoyant

AFAIK $subver is merely a build tag and not part of the advertised version.

I do not understand how adding a SUID bit decreases the attack surface.

eclairevoyant commented on 2022-11-28 21:59 (UTC)

What's the reasoning to split out $pkgver and $subver? Why not just use the upstream version directly in $pkgver?

BTW @hawath hardening != security; hardening is reducing the attack surface but not inherently decreasing the impact of said vulns. See https://bbs.archlinux.org/viewtopic.php?id=254868, https://lists.debian.org/debian-kernel/2020/03/msg00242.html, https://serverfault.com/questions/939455/unprivileged-userns-clone-no-such, and https://lists.debian.org/debian-kernel/2022/11/msg00258.html for context.

edh commented on 2022-11-28 17:59 (UTC)

@hawath I am a bit confused as to why this would make zoom more secure. Setting the SUID bit seems like it would be easier to escalate privileges. Can you elaborate a little?

W47MPUSv commented on 2022-11-23 02:17 (UTC)

Hi: Would you consider adding this line to the PKGBUILD? This is for those users who have set kernel.unprivileged_userns_clone=0 (this is the case for linux-hardened kernel). I raise this because this is from the official electron package.

Thanks, Hawath

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 80 Next › Last »