Package Details: zoom 6.2.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: 669
Popularity: 7.26
First Submitted: 2015-08-15 13:18 (UTC)
Last Updated: 2024-10-28 11:11 (UTC)

Pinned Comments

arash-m commented on 2024-09-15 15:56 (UTC)

Tested 6.2.0-1. Sharing works for me, but it still crashes after stopping. The workaround for me is still downgrading pipewire and libpipewire to 1.0.7 before meetings.

a172 commented on 2022-06-13 14:25 (UTC) (edited on 2022-06-13 14:25 (UTC) by a172)

@edh - That's not the answer I was hoping for (I was really hoping we could get it to launch without xwayland), but at least I know I'm not missing something.

Some ~/.config/zoomus.conf updates:

  • SSO Login: I don't have qt5-webengine installed, and the ebeddedBrowserForSSOLogin line doesn't exist in my config zoomus.conf. SSO login works just fine (issues with Firefox containers aside).
  • Audio: I am using Pipewire via pipewire-pulse. system.audio.type defaulted to alsa for me (or I changed it without realizing it). I probably could have installed pipewire-alsa and fixed my issues, but I set system.autio.type=pulse (a lucky guess) and this worked. This should work for anyone using straight PulseAudio as well.

If anyone finds documentation on ~/.config/zoomus.conf, please let us know.

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 .. 17 18 19 20 21 22 23 24 25 26 27 .. 77 Next › Last »

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

AlexBocken commented on 2022-11-08 12:35 (UTC)

I'm not sure whether this is a packaging issue but with recent updates (last few months) SSO does not work properly anymore. After entering the subdomain for sso (e.g. <yourcompany> for <yourcompany>.zoom.us) the opened link opens up with <yourcompany>/foobar instead of the proper <yourcompany>.zoom.us/foobar Manually adjusting the SSO link to be in the latter format fixes it.

karabaja4 commented on 2022-11-08 01:34 (UTC) (edited on 2022-11-08 01:38 (UTC) by karabaja4)

@kuzyn: Read this: https://community.zoom.com/t5/Meetings/An-empty-folder-created-in-Ubuntu/m-p/69059

Apparently, when XDG_DOWNLOAD_DIR in $HOME/.config/user-dirs.dirs is set to an "unsafe" directory, Chrome CEF decides to create $HOME/Downloads instead.

Setting XDG_DOWNLOAD_DIR in $HOME/.config/user-dirs.dirs to a directory inside my $HOME directory (e.g. $HOME/downloads) helped, so Zoom is no longer creating the annoying Downloads folder.

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 25 26 27 .. 77 Next › Last »