Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

Scotty2019

I have disabled teamviewerd.service for security reasons with "sudo systemctl disable teamviwerd.service". I only start the service when I actually need to use Teamviewer.

I notice that every Teamviewer update overwrites the systemd configuration and re-enables the background service without my consent. I am not happy with the behaviour of Teamviewer updates und would highly recommend to modify the installation script in a way that the user is asked if the startup configuration should be changed or not. This is common practice in the Linux world.

My system: Ubuntu 18.04 64bit.

Find more posts tagged with

Linux

Comments

HudsonSantos

I'ts August 2021 and people still suffering for years with this annoying teamviewerd.service upgrades that doesn't even provide a changelog..

Even though @PauloASilva provided excellent quality shellscript code with basically the solution itself. Unbelievable.

Cronjob from @GenericIT is just amazing. Shameful to have to use such a workaround of this level for a solution like teamviewer, but ok.

I think even another alternative, also shameful, is to uninstall the product from our computers, and re-install it right in the moment we need it back again.

Kerstin_PO

Hi @PauloASilva , @ivosm, @GenericIT, @Ach3Ahp9 , @Scotty2019 and all other community users,

thanks a lot for pointing out this issue and sorry for the late answer. We are very sorry for the inconveniences.

We've discussed the issue with the development team and want to provide a fix so that an update will not overwrite the service settings in the future. Unfortunately, we cannot yet promise any release date.

Thanks a lot for using TeamViewer and providing your valuable feedback!

Best

Kerstin

PauloASilva

This is something that also annoys me for a long time.
Recently I tweeted to @teamviewer_help and they were, at least, responsive.

As I said in one of my tweets I would be glad to help fixing this.
I had a look at the RPM postinstall script to understand what changes would be required.The following changes should do it for systemD but a little bit more effort is required to support other tecnologies.

*** postinstall.sh.orig 2020-05-28 10:59:00.**Please do not post TeamViewer IDs** +0100
--- postinstall.sh      2020-05-28 10:58:36.**Please do not post TeamViewer IDs** +0100
***************
*** 25,35 ****
  {
    local installCount="$1"
    local action=$(RPMAction)

!   [ "$action" = 'upgrade' ] && removeDaemon  # during upgrade: remove daemon, then reinstall

    Configure
    UpdateIconCache
  }

  function Configure()
--- 25,48 ----
  {
    local installCount="$1"
    local action=$(RPMAction)
+   local daemonStatusBeforeUpgrade

!   if [ "$action" = 'upgrade' ]; then
!     # save daemon status so that it can be restored after the upgrade
!     daemonStatusBeforeUpgrade=$( cmdDaemon 'status' )
! 
!     removeDaemon  # during upgrade: remove daemon, then reinstall
!   fi

    Configure
    UpdateIconCache
+ 
+   # restore service status before the upgrade
+   case "$daemonStatusBeforeUpgrade" in
+     disabled)
+       cmdDaemon 'disable'
+       ;;
+   esac
  }

  function Configure()

If there's a plan to implement such a fix, I am available to provide additional help.

Cheers,
Paulo A. Silva

ivosm

There are sure solutions like cron script but I am convinced, that sw is very much about trust and the question is, how can I trust sw incl. its producer, who enable access to my computer despite I refused it.

1. Such an importatnt item should be manageble and visible even by very stupid user because of even he/she has the right to make the decision when exactly to open and when to close this door. So even workable commandline solution is bad.

2. I had a problem with teamviewer even before, because of I didn't see a clear description, who has the control of the permission list? Is that done e.g. by some keystore on my computer (where:?) or is that somewhere at Teamviewer server? I.e. is that technically possible, that Teamviewer company "changes my decision" simillarly to the one of not starting the service?

The second item was a blocker for me for professional use, the mentioned re-enabling of running in background means sorry for my mum, who likes it.

From my point of view is the only solution uninstall and check some possible residuals.

GenericIT

I agree with this, especially since it is pulling logs from other services on the system. For now I am running the following cronjob.

@reboot /usr/bin/bash -c '[ `systemctl is-enabled teamviewerd` != 'disabled' ] && systemctl disable --now teamviewerd'

Ach3Ahp9

I've been running into this problem for a while, too, and was hoping that the company Teamviewer would eventually fix this on their own. That didn't happen.

This is incredibly annoying as I have to manually disable and stop teamviewer on every update. If your daemon is disabled, it should *stay* disabled.

Please remove that "feature", thanks.